Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lll-winken!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: setuid (euid) after setuid (uid) on System 5
Message-ID: <1297@auspex.UUCP>
Date: 26 Mar 89 23:03:26 GMT
References: <123@cat.Fulcrum.BT.CO.UK> <280@cbnewsc.ATT.COM> <1196@auspex.UUCP> <9213@j.cc.purdue.edu>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 18

>Does anyone know what security holes are plugged by this behavior?

Are you assuming the reason that behavior was specified was to plug
security holes? As far as I know, there *aren't* any security holes
plugged by that behavior, and that the reason it was specified wasn't
security - it was backwards compatibility with programs such as "su"
that ran set-UID "root" and that used "setuid" to set the effective
*and* real UIDs to that of the specified user; those programs were
trying to create a new environment with that UID, and would want to set
all the UIDs, including the saved set-user ID, to the specified value. 

>Protecting one part of a program from other parts of itself doesn't make
>sense to me, so there must be a backdoor I am missing.

Why do you assume that there is such a backdoor, or that you're missing
something? Perhaps it was System V that was missing something, namely a
procedure that can be told explicitly to set only the effective UID or
to set all the UIDs for a process.