woods@eci386.uucp (Greg A. Woods) (12/21/90)
In article <1990Dec16.221025.24838@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > In article <1990Dec14.171022.4992@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: > >$ ls -l /usr/mail/root > >-rw-rw---- 1 root mail 27820 Dec 12 05:18 /usr/mail/root > >$ MAIL=/usr/mail/root LOGNAME=root /bin/binmail -F woods > >binmail: Invalid permissions > >binmail: Cannot install/remove forwarding without empty mailfile > > >Hmm... Yup, it seems secure to me! Doesn't mean non-superuser chown > >is OK, but IMHO it *is* not only OK, but useful! > > Oops, when I said empty file I meant no file (my mail reader always deletes > the file when it is empty). OOPS! You're right! It does let me steal a user's (potential) mail! > Does your mail reader always leave a 0 length file in /usr/mail when you > delete all the messages? Does everyone on the system use the same reader > (or do they all do this)? Is there ever a time when a user does not > have a file in /usr/mail (say before they have ever received any mail)? I do prefer to have the 0 byte file in /usr/mail. Certainly mailx and mush can be told to leave it there (most of the time, though mush will delete it if you use '-u user' or '-f mailfile'). I'm not sure about /bin/mail itself, though I suspect it always deletes empty mailboxes. I don't care to try it, and I'm reasonably sure nobody here still uses it to read mail. Yes, the file is only created when a user first receives mail, though I'll now make it a practice to create an empty file for new users, and I've added an empty file for each system id. > IMHO it would be just as useful if it didn't chown the forwarding file > but left it owned by the uid that actually gave the command. That might be a partial hack to at least show the culprit, but the correct one is to check if you are the right person before blindly doing such a drastic thing as forwarding. Seems to me that it's a simple bug that needs fixing, and it certainly doesn't have anything to do with non-root chown(2)'s being harmful! Follow-up's directed to comp.bugs.sys5. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
les@chinet.chi.il.us (Leslie Mikesell) (12/22/90)
In article <1990Dec20.182455.17753@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: >OOPS! You're right! It does let me steal a user's (potential) mail! >> IMHO it would be just as useful if it didn't chown the forwarding file >> but left it owned by the uid that actually gave the command. >That might be a partial hack to at least show the culprit, but the >correct one is to check if you are the right person before blindly >doing such a drastic thing as forwarding. Seems to me that it's a >simple bug that needs fixing, and it certainly doesn't have anything >to do with non-root chown(2)'s being harmful! But wait - there's more! At least one of the replacement mailers will: (A) allow forwarding to programs when "|command" is found in the forwarding file. (B) run the program under the uid of the recipient of the message. (C) perform a security check before doing (B), based on the ownership of the forwarding file. These add up to a serious problem that wouldn't exist if the ownership of a file meant that either the owner or root wanted it that way. Les Mikesell les@chinet.chi.il.us
hansen@pegasus.att.com (Tony L. Hansen) (12/23/90)
< But wait - there's more! < At least one of the replacement mailers will: < (A) allow forwarding to programs when "|command" is found in the < forwarding file. < (B) run the program under the uid of the recipient of the message. < (C) perform a security check before doing (B), based on the ownership < of the forwarding file. The SVr4 mail program gets it right. It does the right thing in setting up mailboxes, setting up forwarding (including forwarding to |command), and does it all with chown() enabled on the system. Tony Hansen att!pegasus!hansen, attmail!tony hansen@pegasus.att.com