Kbase P12157: Who should own a process which has the SETUID ROOT bit on and a ps command is run?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/5/2009 |
|
Status: Verified
GOAL:
Who should own a process when the SETUID ROOT bit is on and a "ps" command is run on a UNIX Machine?
GOAL:
Who owns a process when all database files owned by a non-root userid.
FACT(s) (Environment):
UNIX
Progress/OpenEdge Product Family
FIX:
In the past most UNIX platforms the UID in a ps listing will be who ran or called the process even if the SETUID bit is on. However, this is no longer the case on "most" UNIX platforms. Some platforms like Sun Solaris, AIX and Linux, a process with the SETUID ROOT bit on, will show the UID as "root" regardless who ran or called the process. On some platforms, _mprosrv processes are owned by and have the permissions of root even after Progres has downgraded to the effective userid of the user that started it.
It is true that the server processes (and background I/O processes) on UNIX execute with root privileges. This happens because the executables have "setuid root" file attributes. This has been the case since at least version 5.
The client executables, such as _progress, also have setuid root file attributes, but they use them a bit differently. The client processes lower their privileges after initialization is completed and run with the invoking user's real user and group id.
The servers and background processes do not lower their privileges.
There are several reason why Progress does this.
1. In order to raise the ulimit beyond what the user is allowed. This is done because database files are often very large.
2. In order to be able to open database files that cannot be accessed by the user. This is done so that you can set the protection mask for the database files so that only the owner (or system) has access to them. The database code accesses them on behalf of the user who has no access rights. This is a good thing.
3. The broker process needs to be able to send signals to user processes for various purposes and needs elevated privileges in order to do that.
It is possible in some cases to run a database without using elevated privileges, but requires careful setup.
As an example:
1. There should be an account called "progress" and the executables setuid should also be "progress".
2. Make the database files owned by "progress" so normal users cannot open them.
This does not resolve all problems as there is still the ulimit issue and the fact that the broker needs to send signals. This can also be worked around this by:
3. Having all the database users belong to the same group as the "progress" user.
If there are no self-serving clients using the database, then the _progres executables don't need elevated privileges because they don't access the database directly. However, if there are, then the "progress" user will have to have elevated privileges also.