[dovecot] Dotlocking doesn't work?
A Debian developer had this to say:
Files in the above dir are group mail, and the dir is group mail. However, all binaries in /usr/lib/dovecot are root/root. I have set them all to g+s, and group mail, and now the imap process can lock the INBOX.
imap should be the only one that needs to be setgid mail.
Actually, I've looked at the dovecot source code. There is no way having setgid on the executable will work. The source drops the privledges long before it tries to do a dotlock.
This is an upstream problem.
For now, I've disable dotlock, and use fcntl instead, as that is what exim uses anyways.
Is dotlocking still a work in progress or are we missing something here?
-- Jaldhar H. Vyas jaldhar@debian.org La Salle Debain - http://www.braincells.com/debian/
On Wed, 2003-03-19 at 16:04, Jaldhar H. Vyas wrote:
Files in the above dir are group mail, and the dir is group mail. However, all binaries in /usr/lib/dovecot are root/root. I have set them all to g+s, and group mail, and now the imap process can lock the INBOX.
Is dotlocking still a work in progress or are we missing something here?
Only solution for now is to set /var/mail world-writable and sticky.
Another way would be to use more privileged process for handling lock files. Some programs use setuid or setgid binary for that. I was thinking that I'd let imap process request the locks from master process. That would also allow overriding stale lock files created by other users with shared mailboxes.
On Wed, 19 Mar 2003, Timo Sirainen wrote:
Only solution for now is to set /var/mail world-writable and sticky.
Debian policy doesn't like that.
Another way would be to use more privileged process for handling lock files. Some programs use setuid or setgid binary for that. I was thinking that I'd let imap process request the locks from master process. That would also allow overriding stale lock files created by other users with shared mailboxes.
I think this is a better idea overall. It would reduce the amount of code which needed elevated privileges and like you said, allow stale lock files to be overriden. I used to have that problem with uw-imap.
In the meantime, could you add something to the documentation about this issue?
-- Jaldhar H. Vyas jaldhar@debian.org La Salle Debain - http://www.braincells.com/debian/
Timo Sirainen wrote:
On Wed, 2003-03-19 at 16:04, Jaldhar H. Vyas wrote:
Files in the above dir are group mail, and the dir is group mail. However, all binaries in /usr/lib/dovecot are root/root. I have set them all to g+s, and group mail, and now the imap process can lock the INBOX.
Is dotlocking still a work in progress or are we missing something here?
Only solution for now is to set /var/mail world-writable and sticky.
Another way would be to use more privileged process for handling lock files. Some programs use setuid or setgid binary for that. I was thinking that I'd let imap process request the locks from master process. That would also allow overriding stale lock files created by other users with shared mailboxes.
On this tack, this problem bit me yesterday when I migrated one of my public-access machines from Qpopper to Dovecot on the POP3 side of things. The best way I could solve this, until something can be done for dotlocking is to use fcntl(2) for now.
Though I seem to remember some manner of warnings using fcntl(2). However, since none of my systems use NFS for their mailstores, I felt this is safe enough. Any thoughts on this matter?
--Ian.
participants (3)
-
Ian R. Justman
-
Jaldhar H. Vyas
-
Timo Sirainen