Aucbvax.3046
fa.unix-wizards
utzoo!decvax!ucbvax!unix-wizards
Thu Sep 10 03:12:01 1981
setuid cleared on write
>From pur-ee!bruner@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@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)
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.