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
rws@expo.lcs.mit.EDU (Bob Scheifler) (01/07/91)
IMO, the X build procedure should instead use the LD_LIBRARY_PATH
environment variable
My understanding is that -L paths are preferred over LD_LIBRARY_PATH at
link time. So, if we follow your suggestion, we run into the possibility
of trying to link against old installed versions of the libraries instead of
the new ones in the build tree. Not acceptable.stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) (01/07/91)
In article <9101062227.AA00196@expire.lcs.mit.edu> rws@expo.lcs.mit.EDU (Bob Scheifler) writes: > > IMO, the X build procedure should instead use the LD_LIBRARY_PATH > environment variable > >My understanding is that -L paths are preferred over LD_LIBRARY_PATH at >link time. So, if we follow your suggestion, we run into the possibility >of trying to link against old installed versions of the libraries instead of >the new ones in the build tree. Not acceptable. Why not simply relink the binary with the installed libs in the install target of the makefile (using absolute paths, of course) ? -- Andreas Stolcke stolcke@icsi.berkeley.edu International Computer Science Institute stolcke@ucbicsi.bitnet 1957 Center St., Suite 600, Berkeley, CA 94704 (415) 642-4274 ext. 126
per@erix.ericsson.se (Per Hedeland) (01/07/91)
In article <9101062227.AA00196@expire.lcs.mit.edu>, rws@expo.lcs.mit.EDU (Bob Scheifler) writes: |> |> IMO, the X build procedure should instead use the LD_LIBRARY_PATH |> environment variable |> |> My understanding is that -L paths are preferred over LD_LIBRARY_PATH at |> link time. Yes, I believe that is (unfortunately) true... |> So, if we follow your suggestion, we run into the possibility |> of trying to link against old installed versions of the libraries instead of |> the new ones in the build tree. Not acceptable. Perhaps I wasn't clear enough; what I meant was of course that LD_LIBRARY_PATH should be used *instead* of -L options (and the current -L options *only* specify directories in the build tree, I believe). The possibility of linking against old installed libraries is exactly the same as with the current -L specifications. (There is perhaps a greater possibility that old installed libraries get used for test runs of binaries in the build tree, though - LD_LIBRARY_PATH must be set for such test runs too.) While -L paths specifying installation directories if they're not in the "standard" list would be a good use of the "remembrance" of -L specifications, there is as far as I can tell no support for installation in non-standard directories in the current build procedure, and addition of this feature (if it was possible) should be independant of the fixing of the security problem. --Per Hedeland per@erix.ericsson.se or per%erix.ericsson.se@uunet.uu.net or ...uunet!erix.ericsson.se!per
rws@expo.lcs.mit.EDU (Bob Scheifler) (01/07/91)
Why not simply relink the binary with the installed libs in the install
target of the makefile (using absolute paths, of course) ?
Yes, we've thought of that. But not everyone uses "make install" to
install things, so it still leaves open a possibility of error.rws@expo.lcs.mit.EDU (Bob Scheifler) (01/07/91)
Perhaps I wasn't clear enough; what I meant was of course that
LD_LIBRARY_PATH should be used *instead* of -L options
Then non-standard installation directories could not be made to work by default.
The possibility of linking against old installed libraries is exactly
the same as with the current -L specifications.
I don't think so, since I believe the -L we specify in the command line gets
searched before the default place, not after.
there is as far as I can tell no support for
installation in non-standard directories in the current build procedure,
A bug which should be fixed, as so many have rightfully flamed.
and addition of this feature (if it was possible) should be independant
of the fixing of the security problem.
How, pray tell?stolcke@icsi.berkeley.EDU (01/08/91)
> Why not simply relink the binary with the installed libs in the install > target of the makefile (using absolute paths, of course) ? > > Yes, we've thought of that. But not everyone uses "make install" to > install things, so it still leaves open a possibility of error. Sure, but that's always the case when people use a method other than the recommended or supported one: they're on their own. --andreas
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
per@erix.ericsson.se (Per Hedeland) (01/08/91)
|> The possibility of linking against old installed libraries is exactly |> the same as with the current -L specifications. |> |> I don't think so, since I believe the -L we specify in the command line gets |> searched before the default place, not after. As is the case with LD_LIBRARY_PATH - excerpting from SunOS 4.1 ld(1), "Object File Processing": ld searches for the desired object file through a list of directories specified by -L options, the environment vari- able LD_LIBRARY_PATH, and finally, the built-in list of standard library directories: /lib, /usr/lib, and /usr/local/lib. |> there is as far as I can tell no support for |> installation in non-standard directories in the current build procedure, |> |> A bug which should be fixed, as so many have rightfully flamed. |> |> and addition of this feature (if it was possible) should be independant |> of the fixing of the security problem. |> |> How, pray tell? Please note the "if it was possible" - I just wanted to point out that they are two separate problems, and that a fix for the security problem shouldn't necessarily be required to *also* solve the non-standard-install problem. If it is impossible to solve both (and I certainly don't see a way to do it "atomically"; see below though), I for one would definitely prefer to see a fix for the security problem. |> [ Andreas Stolcke writes: ] |> Why not simply relink the binary with the installed libs in the install |> target of the makefile (using absolute paths, of course) ? |> |> Yes, we've thought of that. But not everyone uses "make install" to |> install things, so it still leaves open a possibility of error. But if the build is done with LD_LIBRARY_PATH (and no -L), and relink (with -L specifying the installation directories) is done in the install target, the only possible error that I can see is that those who want to install in non-standard places, but skip the "make install", won't get (correctly) working installed binaries. I.e. the security hole is closed without any drawbacks compared to the current build procedure, and installation in non-standard places is supported much better than currently, the only requirement being that those who want it do the "make install", or other commands to the same effect ("current" here of course refers to the build procedure of R4 after patch 18 - I don't have information about unreleased fixes for either problem, if such exist). Sounds reasonable to me... --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/11/91)
| From: vallone@oswego.Oswego.EDU (Daniel E. Vallone) | | Why not just use the ldconfig program that comes with SunOS? I thought I had saved the article, but I can't find it. I was informed that ld.so would only retain SUID/SGID permissions on binaries whose shared library references were resolved wholely from libraries in /usr/lib, /usr/5lib, and /usr/local/lib (or libraries found in directories specified with -Ldir.) Unfortunately these restrictions and exceptions aren't documented in ld(1). Is this restriction true/not true? Even if I can has SUID/SGID objects bound to libraries in other directories, I'd still want what I've described because I want to have ld.so search a directory that I *don't* want it to retain SUID/SGID permissions on. I want to be able to specify the following: /usr/lib SUID|SGID /usr/5lib SUID|SGID /usr/local/lib SUID|SGID /usr/local/lib/X11 SUID|SGID /usr/new/lib NOSUID|NOSGID Casey
david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) (01/11/91)
rws@expo.lcs.mit.EDU (Bob Scheifler) writes: } } Why not simply relink the binary with the installed libs in the install } target of the makefile (using absolute paths, of course) ? } }Yes, we've thought of that. But not everyone uses "make install" to }install things, so it still leaves open a possibility of error. I tried this exact approach in the latest release of Wcl. There are new install rules provided to do this. (Install.rules). It works well on all the machines I've tried it on. Should be interesting to hear how well it works for others .