Kbase P71275: Compile-Time Security and Run-time Security
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
28/08/2009 |
|
Status: Verified
SYMPTOM(s):
Compile-Time Security and Run-time Security
** Insufficient access privilege for table <name>. (978)
** Insufficient access privilege for table <table>. (234)
** Invalid access to change security for <file name> File. (499)
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.x
OpenEdge 10.x
CAUSE:
The Progress 4GL supports compile time security only. The security created through the security administration tools (Data Administration / Admin / Security / Edit Data Security) is ignored when running a compiled program (.r).
None of the security restrictions defined in the database are stored in r-code. The compiler analyzes all statements in programs to ensure that the currently connected database userid has appropriate permission to execute these statements and, if they don't, no r-code is produced. Instead an error is produced to the effect of "Insufficient access privilege"...
The only exception to that is when the tables involved are metaschema tables.
In that case, the enforcement might be done at runtime in some cases.
You might encounter the errors when accessing some metaschema tables that your userid does not have access to, or trying to change the security through a 4GL program.
FIX:
In order to enforce permissions restrictions that have been applied to tables and fields in the Edit Data Security dialog, you must do one of the following:
- Your application will have to control the security at run-time. This is done by finding the _file or _field record associated with the table\field that is being modified and check if the currently connected user is in the list or if the permission string equals *. Or you could use the CAN-READ, CAN-WRITE, CAN-DELETE and CAN-CREATE functions using the buffer handle and the connected user.
- Change your application to use dynamic buffer access to modify all tables and fields in the database. Since the buffer a dynamic buffer object points to is defined at runtime then the permissions cannot be checked at compile-time and this check is put off till run-time.
- Run uncompiled code (compile on-the-fly). This would require a development license in the deployment environment and the permissions errors will be visible to your users, but this would effectively protect your data by enforcing the permissions settings for all tables/fields that have them defined.
- Upgrade to OpenEdge release 10.1A or later. In 10.1A the new "Use runtime permissions checking" option was added to the new "Database Options" dialog in the Data Administration tool (Data Administration / Admin / Database Options). This new option causes the client to apply the compile-time security, defined in the "Edit Data Security" dialog, at runtime.
This negates the need to run uncompiled code, add CAN-DO checks in the code or to use dynamic database object access in order to take advantage of the compile-time security at runtime.