[ On Mon, November  7, 1994 at 11:35:10 (-0800), I can teach you how to fish... wrote: ]
> Subject: Re: chown, quotas and security
>
> Well, this has certainly opened an array of pointers to arrays of cans of
> worms...

;-)

> That's the key, right there.  The set?id bits set the *effective*
> {user,group} ID [as appropriate], not the real uid.  If they set the
> real (possibly as well as the effective) ID, there would be no need
> for sete?id, setr?id, set?id to be separate calls, let alone the need
> for them to be called once the program is executed.
> 
> In actuality, suser(), which is called by most system calls, looks at
> cr_uid, which is the effective user ID (cr_ruid is the real user ID).
> 
> This has been since time immemorial.  Nothing is broken.

GAK!

Of course set?id files set the *effective* ?id.  [[RTFM!]]

Which means chown'ing /usr/sbin/chown to root and making it setuid
completely obliviates anything any one/doc says about it!  ;-)

And it is the way it has to be too, otherwise setuid prgms wouldn't be
of much use, would they [[he says thinking out loud!]].

And it also creates a hole big enough for a freight train being pushed
sideways!

Which is yet another reason why I like the idea of chown(2) supporting
non-super-user functionality for filesystems defining it (eg. a ufs
without quotas enabled).

I guess the real question might be:  "Would such functionality break
POSIX conformance?"

-- 
						Greg A. Woods

+1 416 443-1734			VE3TCP		robohack!woods
Planix, Inc. <woods@planix.com>; UniForum Canada <woods@uniforum.ca>