Re: Dynamic libraries and setuid

>From: pamailman@qed.com (Paul Mailman) >Date: Wed, 23 Apr 97 17:28:18 GMT >X-Informix-List-Id: <news.37046> > >The latest release of Informix that we received (Informix 7.2, SE, Unix >(Unisys OS 1.4)) reorganized the Informix libraries and for the first time >required the use of the environment variable LD_LIBRARY_PATH to specify at run >time the path that the dynamic loader uses to locate Informix's shared >libraries. The libraries are certainly reorganized. You can safely assume that they are reorganized every time you get an upgrade. Also, ESQL/C now supports both dynamic linking (shared libraries) and static linking, and the default is (correctly, in my view) dynamic linking. When dynamic linking is used, the system has to know where to find the shared libraries at runtime. The only place which is used by default is /usr/lib. Since the Informix ESQL/C libraries are not placed in /usr/lib, you have to tell the program where to find them. There are a number of ways of doing this. One of them is via the LD_LIBRARY_PATH variable. Another is the LD_RUN_PATH variable, and yet another is by adding -R$INFORMIXDIR/lib -R$INFORMIXDIR/lib/esql to the linking command line. This is probably the neatest way of doing it, especially if the program will be run with the ESQL/C libraries installed in the same place on all machines where the executable will be run. It can be overridden by the LD_LIBRARY_PATH and LD_RUN_PATH variables, too. >After rebuilding under Informix 7.2, several of our ESQL programs can no >longer execute. The dynamic loader reports being unable to find an >Informix library. > >It appears that the problem is those programs that run "setuid", i.e. when >executing they assume the identify of the owner of the program instead of >the person executing the program. Our Unix documentation reveals that for >security reasons if a program runs setuid, the LD_LIBRARY_PATH environment >variable is ignored except for "trusted" directories, of which there is >only one, /usr/lib. Correct. The problem is that I could create my own libxyz.so and fix LD_LIBRARY_PATH so that my library was called instead of the standard libxyz.so, and therefore the function that you thought was safe is actually my own, totally rewritten version of the function which does all sorts of nasty things using the effective UID... >This makes sense from a security standpoint, but what it means, then is that >the default Informix method of linking with shared libraries and using >LD_LIBRARY PATH is no good for setuid programs. Also correct. However, you can get around this by creating a set of symlinks in /usr/lib which point to the corresponding library files under $INFORMIXDIR/lib. This way, the runtime system (ld.so.1, or whatever) finds the shared library in /usr/lib -- which only privileged users can modify, so even if it is a symlink, it points to somewhere which is trustable. This is what OnLine does, as it has a number of programs which use shared libraries -- oninit, onmonitor for example. ESQL/C avoids trampling in the /usr/lib directory because it has no SUID programs of its own, and it is both messy and unpleasant having to modify system directories during the installation process (which makes the C-ISAM installation process singularly objectionable in my mind, but that's another story altogether). >I am eager to hear from other ESQL programmers who have faced this problem >and how you may have solved it. > >I can see several solutions, all with drawbacks: > > - Use archives instead of shared libraries. Disadvantages: larger >executables, possible need to relink for Informix upgrades/fixes, This works, with the stated disadvantages. > - Move Informix shared libraries into /usr/lib. Disadvantages: Messes with >Informix installation files, makes it dangerous or perhaps impossible to have >more than one version of Informix installed on the same machine (which is >important on our development machine when coming up on a new version, and on >our customer machines to minimize downtime when upgrading). As you say, its messy. > - Use environment variable LD_RUN_PATH when linking, to "hard code" the >dynamic library search path into the executable. Disadvantage: need to relink >programs if Informix changes its directory structure yet again. (Despite its >drawbacks, this is my current preference.) > >Does anyone have any other ideas? Surely we're not the first to have faced >this. See above. >I'd appreciate replies or cc's by Email since our darling ISP, PSI, is >occasionally up to two days behind on our news feed. :-( And my responses are currently a couple of days behind too... Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>