In message <m19PQNe-000B44C@proven.weird.com>, "Greg A. Woods" writes:
>[ On Sunday, June 8, 2003 at 17:26:42 (-0700), Greywolf wrote: ]
>> Subject: Re: single user mode file comparisons
>>
>> This implies that if one were to allow mortal chown via some definition in
>> the kernel, chown would be installed in /usr/bin?  This makes no sense.
>
>Yes, and thus it was in a real "UNIX System (TM)".  (/bin in V7 through
>to at least UNIX System V Release 3.2 and of course /usr/bin in SunOS-5)
>
>> You might argue it moot, but as I understand it, the only reason that
>> chown is not allowed by a mortal user to give files away is under the
>> conditions that quota operates.  Since the set[ug]id bits are cleared
>> upon donation, I see no reason not to allow the owner of a file to give
>> away a file (but I'm sure I'm missing something).
>
>You're right on both counts.  :-)
>
>(assuming you mean "when there are no quotas in effect" for the latter)
>
>*BSD systems, which implement quotas, take the safe route and simply
>prevent chown(2) from ever being used by mere mortals no matter whether
>quotas are actually in effect for the underlying filesystem or not.

I've seen BSD software that assumed that the owner of the file was the 
one who created it; the failure of this assumption on System V led to 
security holes.  For example, the upas mailer looked for 'Pipe to' as
the first line in a mailbox, and then did the obvious.  But it ran the 
command under the uid of the *owner* of the file.  So -- edit your own 
mailbox, chown it to root, and send yourself mail... 

I seem to recall some versions of 'at' that had the same problem.

The point is that file system semantics can be tricky....


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)