Subject: Re: single user mode file comparisons
To: NetBSD-current Discussion List <firstname.lastname@example.org>
From: Steven M. Bellovin <email@example.com>
Date: 06/09/2003 22:48:24
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)