Subject: Re: chown, quotas and security
To: I can teach you how to fish... <greywolf@autodesk.com>
From: Chris G. Demetriou <cgd@alpha.bostic.com>
List: current-users
Date: 11/07/1994 16:58:56
> The current state of chown(2) conforms exactly to what Berkeley intended:
> Since quotas may be enabled (as well as other reasons), users should not
> be allowed to give away files as this defeats accounting procedures.
> (Or something to that effect...). The code reflects this.
I wasn't quite sure of all the fun implications of making chown()
legal for non-root users. here are some fun ones:
(1) somebody doesn't have a mail spool file, on a system where
the mail spool directory is mode 1777. i create
a mail spool with their name, give it permissions
such that i can read it, and chown it to them.
(note that 1777 mail spool dirs aren't the default
in NetBSD, but some people prefer them; this isn't
a straw man.)
(2) certain editors (vi, ex) will use a "local" configuration
file, if it exists in the current directory and is
owned by the invoker of the editor.
echo a_fun_ex_command > /tmp/.exrc ; chown root \
/tmp/.exrc
INSTANT TIME BOMB!
unless i'm presented with _very_, _very_ strong motivation for
allowing chown() to normal users, in my opinion this presents too
large a set of potential holes to be allowed. I don't think i'd even
entertain the idea of allowing the sysad to set up the standard
chown(8) (e.g. by making it set-id, or something) to allow users
to give away files.
It's just _not_ a good idea, regardless of whether or not quotas are on.
cgd