Josip Rodin writes:
On Tue, Jan 12, 2010 at 05:54:56PM -0500, Sam Varshavchik wrote:Josip Rodin writes:On Tue, Jan 12, 2010 at 07:13:50AM -0500, Sam Varshavchik wrote:# authtest mr...@courier-mta.com Authentication succeeded.Authenticated: mr...@courier-mta.com (uid 8, gid 12) Home Directory: /var/spool/maildir/mrsam Maildir: (none) Quota: (none) Encrypted Password: Cleartext Password: (none) Options: (none) That's how I have my mailbox configured in courier-authlib. I get: uid=8(mail) gid=12(mail) groups=12(mail)Just to make sure - because I can't tell from this output - does this test include root running "maildrop -d mail"?maildrop -d mr...@courier-mta.com, in my case.OK, but this is different behaviour from what the bug report is about? This is what I mean: % sudo useradd -m -d /tmp/testmaildrop testmaildrop % id testmaildrop uid=1006(testmaildrop) gid=1006(testmaildrop) groups=1006(testmaildrop) % sudo -u testmaildrop sh -c "echo echo \\\`id\\\` >> ~testmaildrop/.mailfilter" % sudo -u testmaildrop sh -c "echo exit >> ~testmaildrop/.mailfilter" % sudo maildrop -V2 -d testmaildrop < /dev/null ERR: authdaemon: s_connect() failed: No such file or directory maildrop: Changing to /tmp/testmaildrop Message start at 0 bytes, envelope sender=testmaildrop maildrop: Attempting .mailfilter maildrop: Filtering through `id` 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?
my_pw=getpwnam(deliverymode);
if (!my_pw)
nouser();
#if RESET_GID
setgroupid(my_pw→pw_gid);
#endif
setuid(my_pw→pw_uid);
This conditional compilation flag is set up in configure.in:
if test "`ls -ld $TDIR/. | cut -c10`" = "t"
then
MBOX_RESET_GID=1
else
MBOX_RESET_GID=0
fi
TDIR is /var/spool/mail. Basically, the process's group ID gets set only if
configure finds that its sticky bit is set.
Some historical unix platforms had the sticky bit set on /var/spool/mail, and users' mailboxes are owned fully by the users' uid and gid. So /var/spool/mail has the same permission-wise semantics as /tmp.
But on modern platforms, /var/spool/mail does not have its sticky bit set. The directory is owned by group mail, writeable by the mail group, and each mailbox in /var/spool/mail is owned by the userid, and groupid mail. In this environment, for maildrop to be able to create a mailbox in /var/spool/mail, it must be run as group mail. maildrop's binary gets installed as userid root, group mail, setuserid and setgroupid bits set.
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.
Note, that there's extensive discussion of this in maildrop's INSTALL. Search for "RESET_GID" in INSTALL. The only thing I see in INSTALL that might need correcting is the reference to RESET_GID's default value always being 1; that's not true.
pgp8MXgQfyjWk.pgp
Description: PGP signature
