Package: mailbase-0.00-r5 searching for problems in gnu-pop3d (not from Gentoo - mailbox stays locked after fetch), I found following local DOS, introduced in mailbase-0.00-r5.ebuild (marked as fix of #8029). There were clean discussion for this bug, but fix is bad (typo?): fperms 1777 /var/spool/mail There is simple code, which can lock all active mail accounts: cd /var/spool/mail for i in * ; do touch $i.lock ; done Basically 1777 is illegal permissions for /var/spool/mail. There are two legal setups for this directory, which can be found in other UNIX systems: 755 root any_group Only root and setuid root binaries can access mail locks (not recommended because setuid root) 775 root mail Only root and setgid mail binaries can access mail locks Second one is more secure, because apps don't need root permissions. Most applications can succeed with both upper mentioned schemes (and also 1777) and have autodetection of proper mode (except 1777) and use helpers for lock access (for example mutt_dotlock). Sticky flag is not OK - 1777 it can cause also other problems, not only DOS attacks. For example, there is a GNU pop3d locking algorithm: create lock (as root/mail) setuid user remove lock (as user/mail) - EPERM
Created attachment 8903 [details, diff] mailbase.diff This patch fixes permission to wise value.
raker: Do you see any problems with changing the mode on /var/spool/mail?
Please look at discussion of bug 8029. Comment #1 from azarah@gentoo.org recommends 775, not 1777. I think, that changing permissions to 1777 was a mistake.
fixed in -r6
This just went stable, and I'm seeing this from pine: [Folder vulnerable - directory /var/spool/mail must have 1777 protection] Is there a bug in pine, does it just need recompilation, or what? It seems to work, regardless.
Danek : you should post a new bug for the PINE warning. As far as this bug is concerned everything is now ok. I have no clue why PINE complains about the new perms... but net-mail people might have an idea.
I filed bug 74847 for this problem.
Perhaps up and changing the perms on /var/spool/mail without verifying that the clients didn't break wasn't such a great idea... Yes, someone can DoS mail readers by creating .lock files in the mail spool, but that someone is very easy to hunt down and kneecap as their UID is all over the files. As for the gnu-pop3d problem, that's arguably a bug in their code. They should drop perms before creating the lock file. I'm not advocating a 1777 mailspool, just pointing out that you can't arbitrarily change the perms and expect all the sundry mail clients to be okay with it.
I just upgraded to -r6 yesterday and this messed mutt up. Before finding this bug I changed the permissions back to 777 and things just worked. The problem was that mutt believed the inbox was readonly and I couldn't toggle it to write. Since I owned the file in /var/spool/mail and could modify it, I'm not sure exactly what the problem was.
I believe this breaks Postfix. Postfix delivers mail with the privileges of the recipient email. This, for email to be delivered to a new user, the new user must be in the "mail" group. If all users are in the "mail" group, then the DOS attack can still be performed. Postfix does NOT use a setgid mail binary to deliver email. It drops privileges to that of the recipient user.
