Xref: utzoo comp.unix.programmer:965 alt.sources.d:1434
Path: utzoo!utgpu!cs.utexas.edu!usc!randvax!segue!jim
From: jim@segue.segue.com (Jim Balter)
Newsgroups: comp.unix.programmer,alt.sources.d
Subject: Re: -x implementations
Message-ID: <6128@segue.segue.com>
Date: 3 Feb 91 19:52:52 GMT
References: <1943:Jan2619:34:3591@kramden.acf.nyu.edu> <2856@charon.cwi.nl> <8869@star.cs.vu.nl> <1991Jan29.153242.12335@convex.com> <8896@star.cs.vu.nl> <19017@rpp386.cactus.org> <6124@segue.segue.com> <8920@star.cs.vu.nl>
Reply-To: jim@segue.segue.com (Jim Balter)
Organization: Segue Software, Inc. - Santa Monica, CA. +1-213-453-2161
Lines: 24

In article <8920@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes:
>)2) It only matters if the program calling access has S_ISUID or S_ISGID set.
>
>Not true.

Is this proof by assertion?  Tell me how it's not true.

>)   Why would test be installed with set-uid privileges?
>
>What if the program (e.g. the shell) that _calls_ `test', is setuid?
>(I.e. its effective uid differs from its real uid.)

The shell shouldn't be set-uid if you have any concern for security, but even
if it were, exec pays no attention to the set-uid bit of the caller.  You seem
to be confusing the effects of su, which changes your real and effective uid,
with the setuid bit on an executable.  Doing an su *does not* make your shell
setuid.  Test will only have different real and effective uids if the S_ISUID
bit is set on the executable file.  This not to say that there aren't plenty
of programs that do access calls that break when someone decides to make them
set-uid.  Because there is no effective uid access call, these programs are
forced to use stat, which costs more on many systems (acc/mod/chg times aren't
kept in core because of old pdp11 space constraints), and do their own access
determination based on protection bits, even though such determination is
system-dependent these days, given group sets and access lists.