Xref: utzoo comp.unix.questions:14721 comp.unix.wizards:17149
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: chown (was: at files and permissions)
Message-ID: <10501@smoke.BRL.MIL>
Date: 6 Jul 89 21:13:19 GMT
References: <1894@cbnewsh.ATT.COM> <669@lzaz.ATT.COM> <8072@bsu-cs.bsu.edu> <4884@ficc.uu.net> <18414@mimsy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 39

In article <18414@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>In article <8072@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes:
>>>... BSD allows only root to change file ownership.
>In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>>I certainly hope that V.4 doesn't have this *bogus* restriction.
>The restriction is not bogus, because the system supports disk quotas.

So now the issue becomes:  Is the BSD disk quota system bogus?
Having had it break things I was doing, I hollered loudly enough
that the system administrator who had decided to give me a finite
quota changed it back to infinite.  Not only does an enforced
quota suffer from the same problems as the System V "ulimit", but
messages generated by the system to the "appropriate" interactive
terminal to warn you that you're approaching your quota can cause
all sorts of damage, especially if your "terminal" is a
communication channel, not a human-oriented device.  (5620 DMD or
630 MTG users should recognize the problem.)

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.

Most of my use of "su" on our BSD-based systems is simply to chown
files.  That is indicative of a serious deficiency in normal user
services on these systems.  I would install a set-UID 0 "chown"
(with appropriate checks) except for the hassle I'd get from the
system admins around here.