Xref: utzoo comp.unix.wizards:23727 alt.security:1487
Path: utzoo!utgpu!watserv1!watmath!att!cbnews!junk1
From: junk1@cbnews.att.com (eric.a.olson)
Newsgroups: comp.unix.wizards,alt.security
Subject: Re: SunOS and shared libraries, security aspects
Keywords: sunos shared-libraries (non)security
Message-ID: <1990Aug30.034031.1474@cbnews.att.com>
Date: 30 Aug 90 03:40:31 GMT
References: <1990Aug27.115140.27772@veritas.uucp> <1990Aug27.171211.16272@maverick.ksu.ksu.edu> <1990Aug29.033933.10062@santra.uucp>
Organization: AT&T Bell Laboratories
Lines: 22

In article <1990Aug29.033933.10062@santra.uucp> jkp@cs.HUT.FI (Jyrki Kuoppala) writes:
>[ I'll also send this to security-alert@sun.com ]
>
>In article <1990Aug27.171211.16272@maverick.ksu.ksu.edu>, terry@eece (Terry Hull) writes:
>>Hmmm.   If my memory serves me correctly, executables that are suid
>>root and linked with shared libraries, must have those libraries in
>>/usr/lib or /lib.  Could it be these executables are trying to find
>>shared libraries in /usr/local/lib?  
>
>The shared library path environment variable is not taken into account
>if uid != euid.  This restriction exists to reduce the possiblity of
>trojan horse-style shared libraries owned by the user and executed in
>a privileged state.
>
>It seems, however, that Sun has again hacked together and included in ....

	Hold on... I thought I had been keeping up-to-date...
	but I've never heard of a shared library path environment
	variable!  I can understand the reason for such a thing...

	Can someone please point me to the appropriate mpage for more
	info?  Or is this inappropriate for 386 AT&T 3.2.2?