non-superuser chown(2)s considered harmful

[Anthony DeBoer]

In article <450 at minya.UUCP> jc at minya.UUCP (John Chambers) writes:
>In article <1991Jan7.145146.7589 at gjetor.geac.COM>, adeboer at gjetor.geac.COM (Anthony DeBoer) writes:
>> Awhile back in this thread we were discussing what to do about files in users'
>> directories that they didn't own; I advocated rm'ing them during nightly
>> cleanup and got lightly flamed and somebody else said it would be better to
>> chown them to the user.  
>
>Well, frankly, if I ever discover such a "cleanup" script, I'll drop what
>I'm doing, go super-user, and eliminate the little monster.
>
>Way back when I first stumbled across Unix, one of my first reactions was
>"Wow, a system that actually lets users share files and work together!"
>Now people come along and suggest that this is a bad idea, and that users
>who have the gall to engage in cooperation and sharing of their work are
>to be punished by silently removing their shared files or by jumbling the
>ownership so you can't tell who was responsible for what.  

The original thread concerned the problem of disk resource hogging. Apparently
some systems implement quotas (my system doesn't, and I don't think I miss
them) to prevent a user from taking more than x number of disk blocks. There's
a loophole that if a user can chown his files to somebody else they get
excluded from his quota calculation and he can exceed it.  The discussion was
what to do about this:  change the kernal to disallow users from chown'ing, or
scan for files of other ownership in their accounts and do something about
them.

The 'rm daemon' was suggested on the assumption that other-ownership files in
a person's account were explicit instances of quota-bypassing.  My system's
default UMASK value is 022, which gives me full access and everyone else
read-only access on my files and directories.  Therefore, if a file is in my
account I put it there and I'll be (or should be) the owner.  If I'm going to
be sharing files with others, they can find them in my directory or I'll look
for them in theirs.

You might want a quota system if new users are happily filling the disk every
other week, but that leads straight into the whole area of openness vs.
security.  I'm certainly a lot happier on an open system, but you don't know
who you can trust nowadays. Let your friends write a file and your enemies
will eventually trash it.  Or a well-meaning friend will do it inadvertently.
Yesterday one of my co-workers learned a bit more about uucp and how there's a
practical limit on how much data you can copy to another system at once when
he filled a partition.  We only lost a little bit of incoming mail, according
to our neighboring sysop.

On the whole, though, I'd rather be able to trust people and not have disk
quotas at all.  Take a look at Cliff Stoll's book, "The Cuckoo's Egg".  I can
agree with his attitudes.  Computer users are a community, and we need to
trust each other to get real work done and not have to spend all our time
securing everything.  If someone does violate that trust and do their worst on
my system, I am prepared to take action at that point.  And I'm prepared to
spend time helping new users develop a positive attitude.

>Really marvelous.  But I guess it's to be expected in a society whose
>school system's general term for cooperation is "cheating".  

It's not always that bad.  I was assigned group projects back in college, and
my only major objection was that the person in the group who knew the most
usually wound up doing most of the work and the others didn't learn a lot. 
The problem with the educational system is they're handing out individual
grades and that can logically follow to them wanting to look at each student
isolated from the others.  It's good experimental method and makes sense
considering the general scientific mindset present in any good PhD, but it
does reflect the underlying assumption of individualism rather than teamwork. 
But that's probably a discussion for some other newsgroup.
-- 
Anthony DeBoer - NAUI #Z8800                           adeboer at gjetor.geac.com
Programmer, Geac J&E Systems Ltd.             uunet!jtsv16!geac!gjetor!adeboer
Toronto, Ontario, Canada             #include <std.random.opinions.disclaimer>