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