non-superuser chown(2)s considered harmful

[John R. Levine]

In article <1990Dec8.184047.22221 at mp.cs.niu.edu> rickert at mp.cs.niu.edu (Neil Rickert) writes:
> Why do you completely misinterpret what people are saying.  The problem
>with quotas and non-root chown is that the file is charged against the
>new owner, and the ability to chown allows one to circumvent limits applied.
>
> Any different meaning of quotas would mean that the system would have to
>read the system administrator's mind as to who should be charged for the
>file space.

Does anyone really do quota accounting by the UID of the file?  Consider
the following scenario: User A creates a large file.  User B links to it.
User A then deletes the original link.  If you charge by uid, user A is
charged for the file even though she has no control over it any more, and
might not even be able to see that it exists, depending on B's directory
protections.

It seems to me that the only plausible way to charge for space is to assign
charge responsibility for each directory (with the default being that a
directory is charged to the same user as its parent, so you only have to list
users' home directories) and to add up the sizes of the files in all of s
user's directory, charging 1/Nth of the blocks in an N block file, rounded up.
If users can link to shared public files, you might want to make a pre-pass
that collects the inumbers of public files and not charge users for links to
them.  I did this kind of quota (without the public file hack) under 6th
edition Unix at Yale in 1976.  It's no big deal.

Note that none of this depends on UIDs.  I suppose you might want to restrict
chowns on directories to keep users from ending up with inacessible subtrees,
though it's easy enough to write a privileged recovery utility that would
chmod a directory to 777 if it's a descendant of the user's home.

-- 
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl at iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl
"Typically supercomputers use a single microprocessor." -Boston Globe