per@erix.ericsson.se (Per Hedeland) (01/07/91)
In article <1532@carol.fwi.uva.nl> casper@fwi.uva.nl (Casper H.S. Dik) writes: >ehrlich@cs.psu.edu (Dan Ehrlich) writes: [ various suggestions about how to fix the shared library problem under SunOS 4.1 by ensuring that the binaries get absolute paths into the X build tree for the libraries ] The drawback of this is of course that the installed binaries will try to find the library in the build tree - this may cause spurious failures for these if/when you're building a new, untested version of a library. Even if the new version is OK, binaries that found the library in the build tree, and are still running, will presumably crash when you later remove that library (e.g. after installation). IMO, the X build procedure should instead use the LD_LIBRARY_PATH environment variable, which is not (yet:-) "remembered" by the binaries - it should be possible to incorporate this into the Makefiles with the standard sh construct 'LD_LIBRARY_PATH=<whatever> <cmd>', either for all the linkage rules, or in the toplevel Makefile rules that cause linkage to be done in the lower-level Makefiles. Aside: Something that I've not yet seen mentioned in this discussion is that even the non-set{u,g}id binaries are a security problem with the "remembered" relative paths, although not of the same magnitude - they're material for "trojan" attacks, as in "Hey, mr superuser, I can't run xclock from this directory of mine, perhaps you could try it?" Even the security-conscious superuser with no dot-in-path and/or that searches for bogus versions of the binary is vulnerable... --Per Hedeland per@erix.ericsson.se or per%erix.ericsson.se@uunet.uu.net or ...uunet!erix.ericsson.se!per
casey@gauss.llnl.gov (Casey Leedom) (01/08/91)
| From: per@erix.ericsson.se (Per Hedeland) | | IMO, the X build procedure should instead use the LD_LIBRARY_PATH | environment variable, which is not (yet:-) "remembered" by the binaries - | it should be possible to incorporate this into the Makefiles with the | standard sh construct 'LD_LIBRARY_PATH=<whatever> <cmd>', either for all | the linkage rules, or in the toplevel Makefile rules that cause linkage | to be done in the lower-level Makefiles. Not entirely related, but a constant complaint of mine with regard to the current SunOS shared library mechanism. Ld.so is unable to find libraries unless they're located in one of /usr/lib, /usr/5lib, or /usr/local/lib, or if you do special magic like binding absolute path names into the binary, or have users specify an LD_LIBRARY_PATH, but not for SUID/SGID binaries ... Sound pretty damn confusing and stupid? I thought you'd agree ... I would really like to see a new version of ld.so come out that used a configuration file, say /etc/ld.so.conf. Such a configuration file should specify which directories and libraries ld.so should look through for library references. It should also specify whether libraries found in specific directories and libraries could be ``trusted'' for SUID/SGID binaries. I don't want to get rid of LD_LIBRARY_PATH, but I do want any library found via LD_LIBRARY_PATH to be automatically untrustworthy unless it comes from a directory or library marked as trustworthy in the ld.so configuration file. Unfortunately, I've found Sun to be very unresponsive to users for the last couple of years. Basically I feel like I'm talking to a brick wall. (Witness for instance Sun's response to the tremendous hatred of their type 4 keyboard and their refusal to offer an ``engineering layout'' alternative.) In my view, Sun has completely adopted a Big Company attitude and desperately needs some competition ... I can only hope that companies like Solbourne can offer that competition both in hardware and software. Casey