On Thu, 26 Feb 2009, Timo Sirainen wrote:
On Feb 25, 2009, at 8:55 PM, Mark Hedges wrote:
I tried making all of the binaries root:mail with g+s, same as /usr/bin/lockfile, but this was no help.
It doesn't, because Dovecot starts them as root and then changes the privileges.
Or you could set mail_access_groups (or perhaps it's still called mail_extra_groups in your version) to "mail", assuming /var/spool/mail was owned by group mail and was group-writable.
Setting mail_access_groups works, but the documentation says this is what the mail_privileged_group setting was for:
# Group to enable temporarily for privileged operations. Currently this is # used only for creating mbox dotlock files when creation fails for INBOX. # Typically this is set to "mail" to give access to /var/mail. mail_privileged_group = mail
# Grant access to these supplementary groups for mail processes. Typically # these are used to set up access to shared mailboxes. Note that it may be # dangerous to set these if users can create symlinks (e.g. if "mail" group is # set here, ln -s /var/mail ~/mail/var could allow a user to delete others' # mailboxes, or ln -s /secret/shared/box ~/mail/mybox would allow reading it). #mail_access_groups =
I don't want to set up access for shared mailboxes. Now I am depending on the webmail system not to allow access outside their home directory, which it seems to do okay, so this works, but it doesn't seem as secure.
Is it possible that dovecot internally forgets that creating the dotlock file is a "privileged operation"?
Mark