chown (was: at files and permissions)

[Rob McMahon]

In article <10501 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>So now the issue becomes: Is the BSD disk quota system bogus?  ...  an
>enforced quota suffer[s] from the same problems as the System V "ulimit" ...

Absolutely not.  There is no way we could survive without quotas, although I'm
sure there are environments that do not need them.  We are a University with
typically 2,500-3,000 students and staff registered on our Unix machines, and
a constant shortage of disk space, cpu power, and terminal access.

We have run systems without quotas (4.1bsd and old NFS systems), 1) by
politely mailing the big users, 2) by putting a `top 25 bad guys' in message
of the day to try to shame people, and 3) by running scripts over night to
place people who are over quota in a restricted shell where they couldn't do
much more than remove files.  1) is a major load on our time, and doesn't work
to any significant extent, or at least not without a lot more work and
threats, and generally making ourselves unpopular.  2) has no affect at all to
speak of.  3) is extremely unpleasant for the users.

Quotas win hands down, particulary the Sun/NFS version where you are given a
time limit rather than n logins, both in terms of administration for us, and
`niceness' for the users (they get polite warnings as soon as they go over,
they're given a week to tidy up, they don't get stuck in some ridiculous
environment where they can only `ls', `cat', `mv' ...).  The important thing
is to allow enough headroom between the hard and soft limits so that people
don't suddenly hit the hard limit without warning.

Quotas don't suffer from the all the same problems as `ulimit', because they
affect only files owned by the user, so incautious setuid programs (not that
such exist :-), or programs writing log files don't get caught out by it.  (Of
course `setrlimit(RLIMIT_FSIZE, ...)' does suffer from this, but that's just a
version of ulimit.)

>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 ...

	while :; do
	  mkdir gronk
	  cd gronk
	done

... which every year at least one person does, either by accident, or `to see
what would happen'.  This is not dealt with by ulimit, and can be much more
messy to clean up.  Some versions of `rm -r' can't cope with this, and I've
even seen fsck fail with `pathname too long' or some such.

>and the other is to keep users from accumulating junk that fills the
>available disk.

Not to say quotas are completely without problems.  We get users moving their
junk backwards and forwards to /tmp every night, so that they can stay between
the hard and soft limits indefinitely.  People can't create e.g. lock files in
world writable directories under other people's codes on alternative
filesystems.

>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.

It's probably just because I've never used a system where joe user can chown a
file to someone else, or maybe I'm a bit fik, but can someone explain why
people want to do this ?  What's wrong with just copying a file if you want a
copy owned by someone else ?

Rob
-- 
UUCP:   ...!mcvax!ukc!warwick!cudcv	PHONE:  +44 203 523037
JANET:  cudcv at uk.ac.warwick             ARPA:   cudcv at warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England