[ Search ] [ What's New? ] [ About ]
[ Bugs ] [ Misc ] [ Mailing Lists ] [ Newgroups ] [ NewsWire ] [ Papers ] [ People ]
[ Pictures ] [ Publications ] [ Responce Teams ] [ Tools ] [ Upcoming Events ] [ Web Sites ]

-r-xr-sr-x   2 bin   mail  106496 Oct 12  1989 /bin/mail

The mail spool directory /usr/mail is of course:

drwxrwxr-x   2 bin   mail   13312 Dec 18 21:11 /usr/mail

Any mailbox in /usr/mail looks like:

-rw-rw----   1 root  mail    1444 Dec 18 17:43 /usr/mail/root

Ok, the schme for local mail delivery is easy: some mail user agent (mailx, Elm, GNU Emac's RMAIL, ...) calls /usr/lib/sendmail which in trun calls /bin/mail (from now on referred to as binmail) for local mail delivery. Binmail appends to the mailbox in /usr/mail if it exists. No problem. If the mailbox DOESN'T EXISTS, binmail creates it. Looks good, but... Imagine the following scenario: user badguy sends a message to another user victim. User victim doesn't seem to have a mailbox in /usr/mail. badguy uses malix (any other MUA will do [calling binmail directly also does the trick]) to compose his message; mailx calls sendmail, which in trun calls binmail. As soon as binmail runs, it runs with euid=badguy, egid=mail. Binmail creates /usr/mail/victim: this file is now owned by badbuy. Now binmail does a 'chown("/usr/mail/victim", victim, mail)'. However, in the meantime (the small amount of time that he owned the mailbox) badguy could have done anything he wanted with it. Various options surely spring to mind... Experiments showed that in appr. 80% of all cases you're quick enough to do something nasty with the mailbox. Running binmail nicely increases this percentage of course. Note that this problem only occurs if the mailbox doesn't exist. Well, why doesn't it exist then? Because some MUA's can be configured to unlink the mailbox if it is empty (GNU's RAMIL does it, mailx might, Elm might).