Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: notesfiles
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!hp-pcd!hp-dcd!hpfcls!rml
From: rml@hpfcls.UUCP
Newsgroups: net.unix-wizards
Subject: System V "saved" user id
Message-ID: <132000006@hpfcls.UUCP>
Date: Wed, 20-Jun-84 20:06:00 EDT
Article-I.D.: hpfcls.132000006
Posted: Wed Jun 20 20:06:00 1984
Date-Received: Wed, 27-Jun-84 19:45:54 EDT
Organization: Hewlett-Packard Fort Collins Systems Division - Fort Collins, CO
Lines: 19
Nf-ID: #N:hpfcls:132000006:000:1087
Nf-From: hpfcls!rml    Jun 20 16:06:00 1984

I posted this several weeks ago, but it apparently never made it to most
of the net.  Apologies to those who've seen it before.

System V added the  feature of  "saving"  the  effective  user id across
calls to  setuid(2),  to allow  set-user-id  programs  to  switch  their
effective  user id back and forth between  their real user id and the id
of the  program's  owner.  From reading the code, I have  observed  that
this feature only works as documented  when neither the real user id nor
effective user id is superuser.  When the real user id is superuser (and
the  effective  user id is  not),  setuid  will  always  fail.  When the
effective  user id is  superuser  (and  the  real  user id is not),  the
process can do one setuid to its real user id, but all subsequent setuid
calls will fail.  Can  anyone  tell me why this is so?  It would  appear
that it is intended  to provide  some  security,  but I don't see how it
does  anything  other than  restrict  the rights of the  superuser to do
things permitted for ordinary users.

				Bob Lenk
				{hplabs, ihnp4}!hpfcla!rml