Subject: Re: chown, quotas and security
To: I can teach you how to fish... <>
From: Greg A. Woods <>
List: current-users
Date: 11/07/1994 15:37:41
[ 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.


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

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. <>; UniForum Canada <>