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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
