Josip Rodin writes:
On Tue, Jan 12, 2010 at 08:02:31PM -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.
There's some juggling of userid and groupid that happens as a result of exec(), so exec()in 'id' may itself be changing the picture. The man page for exec(2) says:
The effective user ID of the process is copied to the saved set-user-
ID; similarly, the effective group ID is copied to the saved set-group-
ID. This copying takes place after any effective ID changes that occur
because of the set-user-ID and set-group-ID permission bits.
That does not paint 100% of the picture, but I have a dim recollection of
having to deal with this, in a different context, elsewhere. Try the
experiment I suggested, and see what happens.
pgpMBDHebI8zI.pgp
Description: PGP signature
