Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!j.cc.purdue.edu!aeh
From: aeh@j.cc.purdue.edu (Dale Talcott)
Newsgroups: comp.bugs.sys5
Subject: Re: setuid (euid) after setuid (uid) on System 5
Summary: why?
Message-ID: <9213@j.cc.purdue.edu>
Date: 25 Mar 89 05:29:55 GMT
References: <123@cat.Fulcrum.BT.CO.UK> <280@cbnewsc.ATT.COM> <1196@auspex.UUCP>
Reply-To: aeh@j.cc.purdue.edu (Dale Talcott)
Organization: Purdue University
Lines: 20


> It shouldn't work for root because they decided not to make it work for
> root.

Does anyone know what security holes are plugged by this behavior?  We
have some applications where it would be nice to be able to bounce back
and forth between root and a given user.  Before I change the kernel,
though, it would be prudent to know what I'm letting us in for.

From looking at the source, it seems as if the only processes which end
up with curtailed permissions because of the SYS V behavior are the
current process (which has root permission already until it setuid()'s
to something else) and its children, until they exec().

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.  Can someone shed
some light?

Dale Talcott, Purdue University Computing Center
aeh@j.cc.purdue.edu, j.cc.purdue.edu!aeh, aeh@purccvm.bitnet