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.