Path: utzoo!utgpu!water!watmath!clyde!bellcore!decvax!ucbvax!pasteur!ames!think!husc6!cmcl2!brl-adm!umd5!decuac!macom1!rikki
From: rikki@macom1.UUCP (R.L. Welsh (decuac!macom1!rikki))
Newsgroups: comp.bugs.sys5
Subject: Re: setuid(2) bug?
Message-ID: <3194@macom1.UUCP>
Date: 17 Feb 88 18:07:16 GMT
References: <679@rivm05.UUCP>
Organization: CENTEL Business Information Systems INC.,Rockville, MD.
Lines: 24

From article <679@rivm05.UUCP>, by ccement@rivm.UUCP (Martien F v Steenbergen):
> 
> According to the (System V) manuals from AT&T, Uniq, Nuxi and
> Xenix the chapter about the setuid(2) system call lists:
> 
> 	"...<Setuid> will fail if the real user ID of the
> 	calling process is not equal to <uid> and its effective
> 	user ID is not super-user. [EPERM]..."
> 
The paragraph right before the above says:

	"If the effective user ID of the calling process is not super-user,
but the saved set-user ID from exec(2) is equal to uid, the effective ID is
set to uid."

	By having the setuid bit on in the executable, you are forcing
the job to run as jim (effective ID = 100) which is equal to <uid>.  Looks
like it does what it should to me.

-- 
Rikki Welsh
Centel Information Systems
5515 Security Lane, Rockville, Maryland, 20852, (301) 984-3636
UUCP:	decuac!macom1!rikki