Kbase 18764: LIBPATH and Implications of SETUID on AIX
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
21/08/2003 |
|
Status: Unverified
GOAL:
An explanation of how setting the SETUID bit on a Progress executable can affect the use of a Library Path Environment Variable ($LIBPATH) .
FACT(s) (Environment):
Progress 7.x
UNIX
FIX:
If you turn on the SETUID bit for a file, any execution of the file passes on the permissions or rights of the owner of the file to the user that executed the file.
Progress recommends that you turn on the SETUID bit for executable files for a number of reasons. These reasons can be found in Progress Solution 17896, "Why Progress requires SETUID root for it's executables."
However, when you use executables that have the SETUID bit on and you attempt to use a $LIBPATH across most UNIX operating systems, the SETUID bit ignores $LIBPATH and, by default, looks for any shared objects in /usr/lib.
The $LIBPATH has different names depending upon the UNIX system you use. For example:
Solaris = LD_LIBRARY_PATH
HP/UX = SHLIB_PATH
IBM AIX = LIBPATH
The IBM AIX OS is slightly different then some of the other UNIX systems in that it not only ignores the $LIBPATH when the SETUID is on but it clears the variable as well. For example, if you are running on HP-UX using _progres (with the SETUID on) and attempt to shell out of the Procedure Editor and echo $SHLIB_PATH (if set), you should see the results. But that value does not work because SETUID ignores the value and looks for any shared objects in /usr/lib. In addition, on AIX the value is cleared and you cannot see it set.
This issue is not specific to Progress. For example, if you have $LIBPATH set and you attempt to assign super-user (su) permission to a new user, it will no longer be set. The reason for this is that executable used to run "su" typically has the following permissions:
-r-sr-xr-x 1 root security 15136 Aug 14 1995 su
The SETUID is on here, thus causing it to ignore and clear your $LIBPATH.
To get around the issue of SETUID ignoring the $LIBPATH variable, set up a softlink from /usr/lib pointing to the shared objects that you wish to use. This does not enable the $LIBPATH but it does ensure that when the variable is ignored and the system looks in /usr/lib for those objects there is a link to where they actually reside. Thus, your objects will be found.