Xref: utzoo comp.unix.programmer:984 alt.sources.d:1441
Path: utzoo!utgpu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!caen!uflorida!mlb.semi.harris.com!algol.mlb.semi.harris.com!del
From: del@algol.mlb.semi.harris.com (Don Lewis)
Newsgroups: comp.unix.programmer,alt.sources.d
Subject: Re: -x implementations
Message-ID: <1991Feb6.011305.22636@mlb.semi.harris.com>
Date: 6 Feb 91 01:13:05 GMT
References: <8920@star.cs.vu.nl> <6128@segue.segue.com> <1991Feb4.135842.28500@odin.diku.dk>
Sender: news@mlb.semi.harris.com
Organization: Harris Semiconductor, Melbourne FL
Lines: 23
Nntp-Posting-Host: algol.mlb.semi.harris.com

In article <1991Feb4.135842.28500@odin.diku.dk> thorinn@diku.dk (Lars Henrik Mathiesen) writes:
>jim@segue.segue.com (Jim Balter) writes:
>>In article <8920@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes:
>>>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.

It sounds to me like the effective uid should be set back to the real uid
before doing the exec()?  Actually, I was under the impression that exec()
did this automatically, but I just tried an experiment and found that
I was mistaken.
--
Don "Truck" Lewis                      Harris Semiconductor
Internet:  del@mlb.semi.harris.com     PO Box 883   MS 62A-028
Phone:     (407) 729-5205              Melbourne, FL  32901