Runtime Permissions Checking breaks loading .df for non-Security Admin users

If a database has specific users as Security Administrator and it as Runtime Permissions Checking active, users that aren't Security Administrator but do have permissions to modify the schema cannot load a .df file.

Sep 3, 2019
Knowledge

Title

URL Name

Runtime-Permissions-Checking-breaks-loading-df-for-non-Security-Admin-users

Article Number

000168896

Environment

Product: OpenEdge Version: 11.5.x, 11.6.0 OS: All supported platforms

Question/Problem Description

Runtime Permissions Checking prevents non-Security Admin users from loading a .df file with errors 14362 142.

Users who do have admin rights to change the schema but are not a Security Admin cannot load .df files when Runtime Permissions Checking is enabled.
When a database has specific users as Security Administrator and it as Runtime Permissions Checking active, users that aren't Security Administrator but do have permissions to modify the schema cannot load a .df file.

Steps to Reproduce

The attached repro.zip file contains files & instructions to reproduce the issue: Preparation: 1. Create copy of Sports2000 2. Load _user.d via data admin 3. Disconnect, reconnect as secadmin/progress 4. Under Admin -> Security -> Security Administrators: Make "secadmin" security admin instead of "*" (all users). 5. Under Admin -> Database options-> Switch on "Use Runtime Permissions checking" To reproduce: 1. Connect as dataadmin/progress 2. Try to load the newtable.df -> The load fails with a series of errors, starting with "Permission to write field denied. (14362)" & "** Unable to update _File Field. (142)" 3. Optional: Add a new table to the database via Data Dictionary interface while logged in as dataadmin.

Clarifying Information

Users that have permissions to make schema changes that are not Sec Admins should be able to load new definitions via a .df file
The non Sec Admin users can make schema changes with the Data Dictionary instead of loading a .df file with the schema changes

Defining Security Administrator should only restrict access to these functions:

Edit User List
Change/Display Data Security
Security Administrators
Disallow Blank Userid Access

Error Message

Permission to write field denied. (14362) ** Unable to update _File Field. (142) "** Error during ADD TABLE <name> ** Invalid table attribute." and related errors.

Defect Number

Defect PSC00342545

Enhancement Number

Cause

When a Security Administrator is created, _Can-* fields are set for some of the schema tables so that only those users can update the permissions on tables.

The 14362 142 errors arise because the code in prodict/dump/_lod_fil.p executes an assignment on the _Can-* field.
Assignments on _Can-* fields cannot be done when user is not a Security Admin

The load code should not try to update the _Can-fields if they are not different from the current value (iow the value that is already in the record)

When a new table is added via the Data Dictionary, the _Can* fields are not set because theses are set via a different tool under the Admin/Security menu.

Resolution

Upgrade to OpenEdge 11.6.1 Service Pack, 11.7.0 or later.

The assignment statement in \prodict\dump\copy_fil.i and \prodict\dump\copy_fld.i files was reworked to set _Can-* fields only when the &to and &from are different which prevents them from having to be updated when a non-Security Admin user with admin rights loads a .df file.

Workaround

Option 1: Make sure someone defined as Security Administrator loads the .df files.

Option 2: Make sure that when schema changes need to be applied by loading a .df file, a Security Administrator user temporarily disables Database Runtime Permissions Checking.

Notes

Keyword Phrase

Last Modified Date

9/4/2019 6:48 AM

Runtime Permissions Checking breaks loading .df for non-Security Admin users

Files(1)

Was this article helpful?

Was this article helpful?

Runtime Permissions Checking breaks loading .df for non-Security Admin users

Information

Related Articles