On Wed, Jan 13, 2010 at 07:13:38AM -0500, Sam Varshavchik wrote: >>>> % id testmaildrop >>>> uid=1006(testmaildrop) gid=1006(testmaildrop) groups=1006(testmaildrop) >>>> uid=1006(testmaildrop) gid=0(root) groups=0(root) >>>> That's the problem. After using -d, it changes the user but not the group. >>>> Can you reproduce that? >>> >>> So, invoking maildrop gives it root privileges, and groupid mail. >>> maildrop checks the -d option, changes its userid as specified, >>> leaves the group id at its acquired "mail" uid, then it can create >>> stuff in /var/spool/mail appropriately. >>> >>> That's what it looks like is happening here, to me. The missing link >>> in your situation, apparently, is maildrop binary's setgroupid bit >>> being set. >> >> We use this by default: >> >> % ls -l =maildrop >> -rwxr-sr-x 1 root mail 162676 2008-01-20 23:23 /usr/bin/maildrop >> >> I think we're suffering from the fact that the +s bit sets the effective >> gid, but that gets ignored later. I'm not sure, but it sounds like we may >> need an explicit setgid or something, to make sure we really honor the >> +s bit rather than root's real gid? > > Maybe, maybe not. Instead of invoking 'id' as a child process of > maildrop, try just having maildrop deliver a test message to a new > mailbox, and see what the ownership of the new file becomes.
That part is fine, it sets the group to mail on newly-created mailboxes. But at the same time this maildrop is able to deliver mails to existing files whose group is set to "root" and are group-writable. I created an empty file owned by root:root mode 660 and 'maildrop -d testmaildrop' successfully wrote to it. That side-effect is not supposed to happen. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org