chown (was: at files and permissions)

[Barry Shein]

From: gwyn at smoke.BRL.MIL (Doug Gwyn)
>There seem to me to be two valid services that can be performed
>by a disk "quota" system.  One of them is to prevent runaway disk
>consumption such as
>	cat x >> x
>and the other is to keep users from accumulating junk that fills
>the available disk.  The first problem is dealt with adequately
>by a resource limit mechanism a la ulimit, or more reliably by a
>"dynamic" quota monitor attached to the specific session.  The
>second problem can be dealt with administratively, with periodic
>use of "du|sort -rn" to find where the problems are.  Realistic
>long-term storage quotas really have to be negotiated between the
>users and the system administrator anyway.  These methods of
>providing disk quota services do not encounter the scenario that
>you described for the UID-based quota scheme when the file owner
>is allowed to chown his own file.

No, it can't be dealt with with "du|sort -rn" except on very small
systems where you can probably just say "someone's hogging the disk"
loudly and get the same effect, cause everyone's in the same room
anyhow (ok, I exaggerate, but small systems with perhaps a hundred or
two entries in the password file.) Or, of course, where you charge
hard currency for disk space so the system has built-in feedback which
makes such problems relatively rare (on one system like that at
Harvard I was the "disk hog", but my funds solved the problem simply
enough, they bought me my own washing machine, no tears.)

Consider the system Rob Pike was describing in his recent USENIX talk.
One major component was a large, organization-wide file server. This
is the type of system that easily has tens of thousands of accounts
(that's not unusual, I worked with a non-unix system over the last few
years that had over 15,000 login accounts in the password file.)

You can have dozens if not hundreds of people using more than what was
decided was their fair share of disk every day. So you run this script
and send them mail. So what? So twenty of them went over their fair
share and won't be back for weeks to see your mail (negligently or
otherwise, they may have thought they had a good reason to do whatever
they did) are way over quota and the disk is busting at the seams on
some partitions. Another ten are ignoring you.

Don't tell me, you start moving some of their stuff off to tape. Oh
what fun, let's have about two dozen people to run this system just to
handle sending and answering disk quota mail, putting things to tape,
dealing with irate users who find they were put to tape and are quite
sure you are mistaken and have inconvenienced them (or believe they
can play the political game to make you never do that to them again),
get the stuff off tape, deal with people who are quite sure something
has gone wrong in this restoral not to mention a phone call or two
about how it took so damn long and they now have a dozen people idle
which is costing them about a thousand dollars an hour while you deal
with the others who are being difficult (ie. human), etc etc etc.

Sh*t Doug, I'd own your whole disk farm just by making you do things
by written, signed memo. You'd spend your weekends proposing budgets
for another dozen secretaries.

Obviously little systems don't need quotas very badly (tho, hey, they
solve both problems you describe with one model, why introduce two
systems where one will do?)

The correct answer is that if you personally shouldn't be constrained
to quotas either you should have infinite quotas or access to some
(set[gu]id) program which lets you set your own quotas (so problem #1,
the accidental overrun is still averted, if desirable.)

Disk is a finite, valuable resource. Many organizations must manage
their disk with many users from diverse administrative domains, and
manage it without any realistic chargeback scheme (ie. the disk is
essentially or actually free* as far as any individual user is
concerned.) The simplest, most obvious way to do this is to assign
disk quotas and have the software enforce these quotas automatically
instead of turning some poor sap into your local disk slave heavy.

My suspicion is you've never managed large systems like this or you
wouldn't even dream of suggesting to just send mail to offenders. And
they're not rare (hint: just about every university has at least one,
if not a few dozen, such systems.)

--------------------

* In fact it's often worse than "free" since the disk is being paid
for out of overhead by everyone so anything you can grab for yourself
is a boon to you, kinda like taxes, you actually can win as long as
you're getting more than your fair share and someone else isn't.
Sorry, but that's life, you don't fix it by removing quotas.
-- 
	-Barry Shein

Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202
Internet: bzs at skuld.std.com
UUCP:     encore!xylogics!skuld!bzs or uunet!skuld!bzs