setuid cleared on write

[utzoo!decvax!ucbvax!unix-wizards]

>From pur-ee!bruner at Berkeley Thu Sep 10 03:05:54 1981
	From decvax!ucbvax!unix-wizards Tue Sep  8 02:46:22 1981
	/usr/spool/mail     : fa.unix-wizards
	>From eps at UCLA-Security Mon Sep  7 23:48:16 1981
	f = sfl7(); /* set reasonably high flame level */
	/*
	Resetting suid bits when a file is modified is a loss.  File
	protection is (should be) sufficient to prevent unauthorized
	users from rewriting set-uid files.  "Privileged" users should
	have a umask of at least 2 to impede carelessness.  If your
	kernel allows ordinary users to chown, then suid should be reset
	if the new uid!=euid, and likewise for sgid.  Chown should mask
	off sgid if the file's gid!=egid also.  "The superuser is
	considered sufficiently responsible" so those restrictions
	shouldn't apply for uid 0--but mail is presumably running as
	root.  From various bad experiences with IN[ter]active System's
	VAX/WB I firmly believe that "No mail program should EVER change
	the owner or protection of an EXISTING file."  Perhaps it might
	not be unreasonable for mail to stat(2) a recipient's mailbox and
	mail off an "I suspect a muncher" note to someone appropriate if
	it looks suspicious.  By the way, I've never seen a Unix site
	where /usr wasn't a separate filesystem from the root, if that's
	any consolation (of course there are suid programs in /usr/bin).
	If your mail program keeps mailboxes in /usr/spool/mail (rather
	than appending to a file in users' HOME directories), then I
	don't see any reason why mail has to be setuid.  Make it
	set-gid "mail" and each user can still own his/her own
	mailbox yet the directory and the mailboxes need not be
	other-writable.
						--Eric
	*/
	sflx(f);
	
I would propose that the setuid bit be cleared if the file is written
by someone other than its owner, and similarly that the setgid bit
be cleared if the group-id of the writer doesn't match the group id
of the file.  This way, a user could write upon his own files and
not have to remember to "chmod" them back after each write.  Also,
members of a group (who, in general, cannot "chmod" the file) can
change its contents without clearing the setgid bit.  Users other
than the owner (for setuid) or users outside of the group (for setgid)
could not take advantage of a file accidentally left writable.

--John Bruner
(ucbvax!pur-ee!bruner)