#define AUTHOR "david@spinne.web.net (David Maxwell)"

/*
 * > The chown(2) system call turns off the setuid and/or setgid bits as
 * > appropriate, so this is not a concern.
 *   
 * Actually, I DID test my post on our NetBSD system here to make sure my example
 * was accurate. On many Unixes I've worked on that allowed chown by non-root
 * users, yes the setuids were taken off when the file was given away,
 * however, _root_ was allowed to chown files without the setuid bits being
 * removed. Since chown was setuid in this case, that could be the problem.
 * 
 * 							David Maxwell
 * 							david@spinne.web.net
 */

#undef AUTHOR	/* "david@spinne.web.net (David Maxwell)" */

Spot on.

Making chown(2) setuid is an absurdity in itself, since you have then just
given away your system, but I'm sure we have already reached this conclusion.

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.

The code to strip off the set?id bits is already there, but the check
for being the super-user gets there first and aborts the operation before
the stripping of the bits can actually take place.

Keep in mind the history of chown(2), and note that under pure System V
(did I use an inflammatory term?   Sorry :-)) chown works as shown above:
If you give a file away, the set?id bits are stripped, and if you are
trying to change the group as well, you cannot do that unless you are
in the group in question.  (That's how chgrp works but then you knew that.)






--
 _______Wizardry is dead._____ _____WHO: Greywolf (my nameplate even says so)
/ ___\ _ \ __\ V / \  / /__ \| | __/WHAT: UNIX System Mangler...er, Admin
\ \| |   < _| ` ' \ '` / \/ /|_| _/ WHERE: Autodesk, Inc.  3 Harbor Dr.
 \___|_|\_\__\|_|  \/\/ \__/___/_|  Sausalito, CA 94965 (415) 332-2344 x4219
	see also: gandalf@netcom.com