Xref: utzoo alt.security:1870 comp.windows.x:31236
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!julius.cs.uiuc.edu!rpi!uupsi!sunic!ericom!eua.ericsson.se!erix.ericsson.se!per
From: per@erix.ericsson.se (Per Hedeland)
Newsgroups: alt.security,comp.windows.x
Subject: Re: Suns 4.1 problems with X
Message-ID: <1991Jan6.190603.27364@eua.ericsson.se>
Date: 6 Jan 91 19:06:03 GMT
References: <JODY.90Dec21085131@robulus.shell.com> <SPIKE.90Dec21173919@world.std.com> <1991Jan2.163709.5333@ctr.columbia.edu> <Fl8ef8!3@cs.psu.edu> <1529@carol.fwi.uva.nl> <1532@carol.fwi.uva.nl>
Sender: news@eua.ericsson.se
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Lines: 33

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