[Dovecot] Ubuntu, Exim, deliver: permissions/setgid problem
Hello all,
I have a little problem. I'm trying to set up Dovecot deliver (1.0 beta 3) as the LDA for Exim4 on Ubuntu 6.06 with MBOX, and I'm running into permissions problems. Exim typically wants to run pipes as the user to whom the mail is being delivered (as per the "check_local_user"). deliver needs access to the auth socket and needs to be able to create files in /var/mail.
In Ubuntu, /var/mail is writeable by group mail, but not by others. So I thought I'd make deliver run as the user to whom the mail is being delivered (as per default) and with group "mail" (so it can create files in /var/mail). I also set the auth socket to be group-writeable and gave it the group mail. So theoretically, deliver should be able to:
- connect to the socket
- create dotfiles in /var/mail
- write to the user's mailbox
The problem I'm running into is that deliver tries to setgid to the primary group of the target user, and dies when it can't. I specifically do NOT want it to do this, because regular users don't have permission to write to /var/mail.
I've also tried making deliver SUID root (as recommended on this list) or SGID mail (like procmail is) but I get the same error. If I also disable the "group = mail" line in the dovecot_deliver_user router in exim4.conf, I still get the same error.
If I disable the "group = mail" line without making deliver SUID or SGID, then it can no longer connect to the auth socket. In this case it runs with the group of the user for whom the mail is being delivered, i.e. sam-adm (#10000).
I've also tried adding "user = mail" to the transport, to no avail.
The ONE way I've been able to make it work is to remove "group = mail" from exim4.conf and set the socket's mode to 0666, but I've seen warnings that allowing world-access to the socket is dangerous.
I'm actually not sure why this works, since in this case it's running with both the UID and GID of the target user, and therefore shouldn't be able to create files in /var/mail.
Can anyone untangle this for me? From what I've read, in Debian delivery agents should run with group "mail" (procmail is SGID mail). It seems to me that the way to go is to spawn it with group mail, allow group mail access to the auth socket, and be done with it. But this is prevented from working since it insists on resetting back to the user's primary group.
Thanks, Sam Hathaway
The relevent section of my dovecot.conf looks like this:
protocol lda { postmaster_address = postmaster@uofr.net log_path = /var/log/dovecot-lda.log }
auth default { mechanisms = plain socket listen { master { path = /var/run/dovecot-auth-master mode = 0660 group = mail } } # ... (other auth config directives here) }
And the relevent parts of my exim4.conf are as follows:
# in router section: local_user: debug_print = "R: local_user for $local_part@$domain" driver = accept domains = +local_domains check_local_user local_part_suffix = +* local_part_suffix_optional local_parts = ! root transport = dovecot_deliver_user
# in transport section: dovecot_deliver_user: debug_print = "T: pipe for $local_part@$domain" driver = pipe command = /usr/lib/dovecot/deliver -d $local_part message_prefix = message_suffix = log_output delivery_date_add envelope_to_add return_path_add group = mail
Here are the permissions on some interesting files/dirs:
-rwxr-xr-x 1 root mail 551424 2006-11-22 21:59 /usr/lib/dovecot/deliver drwxrwsr-t 2 root mail 1024 2007-01-25 14:14 /var/mail -rw-rw---- 1 sam-adm mail 544 2007-01-25 15:58 /var/mail/sam-adm srw-rw---- 1 root mail 0 2007-01-25 15:39 /var/run/dovecot-auth-master
And here's how I've been testing:
echo "test" | mail -s "deliver test" sam-adm
When I execute the above command, exim says:
2007-01-25 15:55:01 1HABcb-0006h4-N8 <= sam-adm@vps.uofr.net U=sam-adm P=local S=334 2007-01-25 15:55:02 1HABcb-0006h4-N8 ** sam-adm@vps.uofr.net R=local_user T=dovecot_deliver_user: Child process of dovecot_deliver_user transport returned 89 from command: /usr/lib/dovecot/deliver 2007-01-25 15:55:02 1HABcb-0006h4-N8 Completed
And deliver says:
deliver: "2007-01-25 15:55:02 "Fatal: setgid(10000) failed: Operation not permitted
On 26.1.2007, at 6.01, Sam Hathaway wrote:
I have a little problem. I'm trying to set up Dovecot deliver (1.0
beta 3) as the LDA for Exim4 on Ubuntu 6.06 with MBOX, and I'm running into permissions problems. Exim typically wants to run pipes as the user to whom the mail is being delivered (as per the "check_local_user"). deliver needs access to the auth socket and needs to be able to create files in /var/mail.
If Exim sets the UID/GID already, does it also set HOME environment,
or can you set default_mail_env without relying on the home dir
coming from userdb? In that case if you just don't give -d parameter
to deliver, it won't even try to connect to dovecot-auth and it won't
try to change uid/gid.
On Fri, Jan 26, 2007 at 01:55:46PM +0200, Timo Sirainen wrote:
On 26.1.2007, at 6.01, Sam Hathaway wrote:
I have a little problem. I'm trying to set up Dovecot deliver (1.0
beta 3) as the LDA for Exim4 on Ubuntu 6.06 with MBOX, and I'm running into permissions problems. Exim typically wants to run pipes as the user to whom the mail is being delivered (as per the "check_local_user"). deliver needs access to the auth socket and needs to be able to create files in /var/mail.If Exim sets the UID/GID already, does it also set HOME environment,
or can you set default_mail_env without relying on the home dir
coming from userdb? In that case if you just don't give -d parameter
to deliver, it won't even try to connect to dovecot-auth and it won't
try to change uid/gid.
Would it be possible to add a flag to the LDA which would prevent it from trying to set the UID/GID regardless of the HOME env and stuff?
Or, is it possible to set QUOTA environment variable as well?
-- Jan Srzednicki w@expro.pl
On Fri, 2007-01-26 at 13:11 +0100, Jan Srzednicki wrote:
Would it be possible to add a flag to the LDA which would prevent it from trying to set the UID/GID regardless of the HOME env and stuff?
Possible, yes, but I'm it feels a bit dirty to add yet another option just for that. I'd rather wait until I can figure out a better solution. Or until more people start complaining about this. :)
Or, is it possible to set QUOTA environment variable as well?
You could use -c option to specify a different dovecot.conf which contains plugin { quota = .. }. The config file could be created just for that one deliver run.
on 01/26/2007 06:55 AM Timo Sirainen said the following:
On 26.1.2007, at 6.01, Sam Hathaway wrote:
I have a little problem. I'm trying to set up Dovecot deliver (1.0 beta 3) as the LDA for Exim4 on Ubuntu 6.06 with MBOX, and I'm running into permissions problems. Exim typically wants to run pipes as the user to whom the mail is being delivered (as per the "check_local_user"). deliver needs access to the auth socket and needs to be able to create files in /var/mail.
If Exim sets the UID/GID already, does it also set HOME environment, or can you set default_mail_env without relying on the home dir coming from userdb? In that case if you just don't give -d parameter to deliver, it won't even try to connect to dovecot-auth and it won't try to change uid/gid.
Timo,
Yes, it does set HOME and removing the -d option worked. Thank you! I was wondering if you could help me with the other part of my deliver setup. I'm trying to deliver mail to arbitrary files as specified by pathnames in .forward files. I'm using -m to specify the mailbox. It seems that deliver only accepts mailbox names relative to $HOME/mail, but a .forward file can contain any full path.
With "/home/sam/mail/dovecot-forward-test" in the .forward file, deliver rejects the mail by sending this in a bounce message:
Your message was automatically rejected by Sieve, a mail
filtering language.
The following reason was given:
Invalid mailbox name
Reporting-UA: vps.uofr.net; Dovecot LDA 1.0.beta3
Final-Recipient: rfc822; sam
Original-Message-ID: <E1HBKjs-0004dz-PF@vps.uofr.net>
Disposition: automatic-action/MDN-sent-automatically; deletedIs there any way to convince deliver to arbitrary paths? I tried enabling mail_full_filesystem_access, but that didn't help. -sam
On Sun, 2007-01-28 at 20:23 -0500, Sam Hathaway wrote:
Is there any way to convince deliver to arbitrary paths? I tried enabling mail_full_filesystem_access, but that didn't help.
It's annoying that deliver uses a different way to read its configuration. Also I didn't think about this problem when first naming the environment variables. This will all get nicely fixed in Dovecot v2.0, but for now use:
protocol lda { full_filesystem_access = yes ... }
on 02/05/2007 06:58 AM Timo Sirainen said the following:
On Sun, 2007-01-28 at 20:23 -0500, Sam Hathaway wrote:
Is there any way to convince deliver to arbitrary paths? I tried enabling mail_full_filesystem_access, but that didn't help.
It's annoying that deliver uses a different way to read its configuration. Also I didn't think about this problem when first naming the environment variables. This will all get nicely fixed in Dovecot v2.0, but for now use:
protocol lda { full_filesystem_access = yes ... }
Thanks, that did the trick. -sam
participants (3)
-
Jan Srzednicki
-
Sam Hathaway
-
Timo Sirainen