Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-unix!hplabs!pesnta!altos86!elxsi!beatnix!gww
From: gww@beatnix..UUCP (Gary Winiger)
Newsgroups: comp.unix.wizards
Subject: Re: 4.2BSD: Bug in setreuid()? - (nf)
Message-ID: <187@elxsi.UUCP>
Date: Tue, 16-Dec-86 19:07:12 EST
Article-I.D.: elxsi.187
Posted: Tue Dec 16 19:07:12 1986
Date-Received: Thu, 18-Dec-86 01:54:30 EST
References: <50100001@tub.UUCP>
Sender: nobody@elxsi.UUCP
Reply-To: gww@beatnix.UUCP (Gary Winiger)
Organization: ELXSI Super Computers, San Jose
Lines: 22

In article <50100001@tub.UUCP> net@tub.UUCP writes:
>
>Inspection of the kernel source reveals that setreuid() sets
>u.u_procp->p_uid to the *real* userid, while the kill() syscall expects
>that p->p_uid holds the *effective* userid (in fact, kill checks if
>p->p_uid==u.u_uid).  Note that u.u_procp->p_uid is always set to the
>effective userid by the exec() syscall.
>
>Is this a bug or a feature?  Are processes that have to switch between
>two userids not supposed to send themselves signals?  Is this ``Fixed In 4.3''?
>Comments and/or help are appreciated.

This is indeed a bug.  I reported it to Berkeley and the net over a year ago
when I was at LLNL.  The uid set in the per process area should indeed be the
effective uid and not the real uid.
	(viz. /sys/sys/kern_prot.c:  u.u_procp->p_uid = euid;
	                     not ruid as is in the 4.2 kernel)

It has been corrected in 4.3.

Gary..
{ucbvax!sun,styx,altos86}!elxsi!gww