Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!sundc!netxcom!rfrye
From: rfrye@netxcom.UUCP (Rob Frye)
Newsgroups: net.bugs.usg
Subject: Re: Problems with setuid(), SVr2v2 - (nf)
Message-ID: <102@netxcom.UUCP>
Date: Thu, 25-Sep-86 16:49:31 EDT
Article-I.D.: netxcom.102
Posted: Thu Sep 25 16:49:31 1986
Date-Received: Fri, 26-Sep-86 02:01:17 EDT
References: <4100002@siedap.UUCP>
Organization: NetExpress Communications Inc. Vienna, Va.
Lines: 29
Summary: Works for normal uid's, not for root

In article <4100002@siedap.UUCP>, tim@siedap.UUCP writes:
> 
> The setuid() system call under SVr2v2 (on a 3B2) doesn't seem to do
> one thing which the manual claims it does :
> 
> > If the effective user id of the calling process is not super-user,
> > but the saved set-user (group) ID from exec(2) is equal to uid (gid),
> > the effective user (group) ID is set to uid (gid).
> 
> I'm using a process which has set-uid to root;

[ other info and code example given ]

Same is true on Xenix System V -- apparently you can give up root priv's
by turning on the set-uid bit on an executable owned by someone other
than root, but you can't get them back by doing a setuid() back to
the real uid of 0.  It does work correctly for all other real uid's.

Of course, if you're already root, why give up the privileges in the
first place?  (ie -- don't run setuid programs!)  In our case, we
just set the set-gid bit and have our directories and files 775 mode
for that group -- a normal user executing things becomes real/effective
uid = theirs, real gid = theirs, effective gid = gid of "DS".  When
root runs it, same thing happens and real/effective UID of 0 still
keeps all priv's!
-- 
---

"You can Telenet, but you can't tell it much!"