/usr/spool/mail

[utzoo!decvax!ucbvax!unix-wizards]

>From eps at UCLA-Security Mon Sep  7 23:49:47 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);