This Article explains how OpenEdge interacts with UNIX permissions. It also explains what permissions need to be set in order for the Application environment to run effectively and without permission problems.
The information contained in this Article allows the system administrator to maintain security at the UNIX level in the event that users have access to the operating system shell. While an OpenEdge Install must always be carried out as root, post-install executable and file permissions need to be changed to meet site-specific security requirements. The combination of executable permissions and database permissions provides full functionality as well as the ability to provide security where needed. In order for users to start a multi-user session for OpenEdge, the following permissions should be maintained.
OpenEdge Executables:
- The Owner of the executables should be root
- Progress executables should have read, write, and setuid for the Owner.
- Group and Other should also have execute permissions.
- The setuid bit must not be on: _sqldump, _sqlload, _sqlschema, _sqlsrv2 , _waitfor , _rfutil, _proutil The SUID technique cannot be used for these process as the required libraries in order to function properly will not be loaded. The location of shared libraries is not coded in the binary file, unless there are symbolic links which are not supported are in the /usr/lib directory
- Further detail are provided in Article How should I set permissions for Progress executables and database files on UNIX ?
To change OpenEdge executable ownership and permissions :
1. Log in as root or switch user to root.
2. Move to the $DLC/bin install directory.
3. Change executable ownership and permissions
$ chown root _*
$ chmod 4755 _*
$ chmod 755 _sql*
$ chmod 755 _waitfor
If OE Replication is installed, ownership and executable file permissions for rpserver, rprepl and rpagent:
$ chown root rp*
$ chmod 4755 rp*
The SUID bit
- The SUID bit can only be set for the owner (setuid) and group (setgid) of the file.
- This setuid bit allows the user that executes the file to take on the permissions of the owner of the files while running executables.
- This allows individual users access to the database files while in Progress, but they cannot delete the files when in the UNIX shell.
For example: Once the database is started:
- The suid bit on the _mprosrv executable is downgraded.
- The SUID bit spawns the executed process as if it would be started by the owner of the binary file.
- This technique is used by the database broker (_mprosrv) but cannot be used for the _sqlsrv2 process as the necessary libraries will not be loaded.
Unable to make a SQL connection to a restored database
PROGRESS Database files:
Since the suid bit is downgraded, read and write permissions to all database files are needed for:
- The user who starts the database, in order that any executable subsequently started by the database broker without the suid bit will start (for example _sqlsrv2)
- Each user running the application accessing the database shared-memory with an ABL client or when using the "CONNECT" ABL statement.
- To prevent users from deleting the database files on disk the following permissions should be set.
- Permissions to the directory where the database resides should belong to root and have read, write, and execute permissions.
- The group should be set to the group assigned to the database users and should have read and write permissions only.
- Other users should have no permissions set.
Directory permissions:
drwxr-x--- 2 root support
Directory content:
drwxr-x--- 2 root support 1024 Nov 10 10:18 . # current working directory
drwxrwxrwx 8 root rdl 1024 Nov 10 09:49 .. # parent directory or next higher directory
-rw-rw---- 1 root support 2228224 Dec 2 16:50 demo.b1
-rw-rw---- 1 root support 770048 Dec 2 16:50 demo.d1
-rw-rw---- 1 root support 32768 Dec 2 16:50 demo.db
-rw-rw---- 1 root support 443 Dec 2 16:50 demo.lg
-rw-rw---- 1 root support 31 Dec 2 16:50 demo.st
With these permissions set, only the root user and all users who are part of the group may access the database through Progress, however only root can modify or delete the files from the UNIX shell (due to the directory permissions).
When you use the "connect" statement from within a procedure or through the editor, the use of a networked connection (for example, the -S and -H parameter), you do not need to turn on read and write permissions for "other". Read and write for "owner" will suffice. For further information refer to
CONNECT statement errors with 1136You can enable 'other' people access to the database but if tighter security is what you are after then you should only allow database access to people who are part of the specified Group.
