Text File

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 <jgoerzen@complete.org> 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.