[Dovecot] Permissions when running `dovecot --exec-mail imap`
Hi,
I'm running dovecot 1.2.15, on Debian squeeze. /var/mail is owned by group "mail" with permissions "g+rwxs,o=". The mail_privileged_group setting is set to "mail".
I am trying to access mail on a remote machine with mutt by tunnelling
mutt though ssh and running dovecot --exec-mail imap on the mail
server. But I frequently get errors in the mail server's logs about
not being able to create dotlock files when accessing my INBOX this
way. This makes sense -- I'm running dovecot as a regular user, so it
isn't able to write to /var/mail as group "mail".
I notice that on the dovecot wiki[1] it is suggested that sudo is used
to set uid/gid before running dovecot --exec-mail imap. But I don't
actually want to set the uid, just the gid. And I also have sudo
disabled at the moment. So I was wondering about another solution...
Would it be acceptable to setgid the dovecot executable and change it's
group to "mail" (i.e., chgrp mail dovecot and chmod g+s dovecot)?
Would this pose some kind of security risk? Would this actualy do what
I want, or am I missing a bigger picture?
Kind regards,
[1] http://wiki.dovecot.org/PreAuth
-- Tim Marston ed.am
Hi,
I got no reply about this, so I thought I'd just follow-up...
On Tue, Jan 15, 2013 at 11:33:08PM +0000, Tim Marston wrote:
Would it be acceptable to setgid the dovecot executable and change it's group to "mail" (i.e.,
chgrp mail dovecotandchmod g+s dovecot)? Would this pose some kind of security risk? Would this actualy do what I want, or am I missing a bigger picture?
Just to confirm, doing the following fixed the problem for me:
# chgrp mail /usr/bin/dovecot # chmod g+s /usr/bin/dovecot
I am still able to use IMAP normally, and I am now also able to set up mutt with the following:
set tunnel="ssh -q mailhost '/usr/sbin/dovecot --exec-mail imap'"
My INBOX in no longer occasionally read-only, and I no longer get the following error in /var/log/mail.err:
Jan 22 08:48:59 mailhost IMAP(user): : file_dotlock_create(/var/mail/user) failed: Permission denied (euid=1000(user) egid=1000(user) missing +w perm: /var/mail) (set mail_privileged_group=mail)
I would still like confirmation from a dovecot dev that it is OK to set up dovecot this way. Any comments?
Kind regards,
-- Tim Marston ed.am
On 22.1.2013, at 21.44, Tim Marston tim@ed.am wrote:
On Tue, Jan 15, 2013 at 11:33:08PM +0000, Tim Marston wrote:
Would it be acceptable to setgid the dovecot executable and change it's group to "mail" (i.e.,
chgrp mail dovecotandchmod g+s dovecot)? Would this pose some kind of security risk? Would this actualy do what I want, or am I missing a bigger picture?Just to confirm, doing the following fixed the problem for me:
# chgrp mail /usr/bin/dovecot # chmod g+s /usr/bin/dovecot
I am still able to use IMAP normally, and I am now also able to set up mutt with the following:
You've now basically given any user ability to run any process with mail group privileges.
My INBOX in no longer occasionally read-only, and I no longer get the following error in /var/log/mail.err:
Jan 22 08:48:59 mailhost IMAP(user): : file_dotlock_create(/var/mail/user) failed: Permission denied (euid=1000(user) egid=1000(user) missing +w perm: /var/mail) (set mail_privileged_group=mail)
Other possibilities:
a) Deliver mails elsewhere than /var/mail/ (under each user's home dir)
b) Don't use dotlocking: mbox_write_locks = fcntl
c) Make /var/mail/ 01777 permissions
Hi,
On Wed, Jan 23, 2013 at 10:03:50AM +0200, Timo Sirainen wrote:
On 22.1.2013, at 21.44, Tim Marston tim@ed.am wrote:
# chgrp mail /usr/bin/dovecot # chmod g+s /usr/bin/dovecot
I am still able to use IMAP normally, and I am now also able to set up mutt with the following:
You've now basically given any user ability to run any process with mail group privileges.
OK, I've un-done that. Thanks. :o)
Just out of interest, if I did this:
# chgrp mail /usr/lib/dovecot/imap # chmod g+s /usr/lib/dovecot/imap
and set up mutt to run that insead, would that be any better?
Other possibilities:
b) Don't use dotlocking: mbox_write_locks = fcntl
OK, this looks like a good solution. I will look in to this.
Thanks very much for the help. :o)
All the best,
-- Tim Marston ed.am
participants (2)
-
Tim Marston
-
Timo Sirainen