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