Xref: utzoo comp.unix.programmer:967 alt.sources.d:1437
Path: utzoo!utgpu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!eru!hagbard!sunic!dkuug!diku!thorinn
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.unix.programmer,alt.sources.d
Subject: Re: -x implementations
Message-ID: <1991Feb4.135842.28500@odin.diku.dk>
Date: 4 Feb 91 13:58:42 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> <6128@segue.segue.com>
Sender: news@odin.diku.dk (Netnews System)
Organization: Department of Computer Science, U of Copenhagen
Lines: 25

jim@segue.segue.com (Jim Balter) writes:
>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.

It simply isn't. (Reason below.)

>>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.

But exec (and fork) don't care about the real uid either, so it is
just inherited. If a shell has different real and effective uids, any
process run by that shell will too (unless it happens to be setuid to
the real uid). And the shell in its turn could have been started by a
setuid program that has a reason for being so.

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn@diku.dk