[Dovecot] invoking LDA in .forward
Hi,
We're running a Debian server with system users where the mail is by default delivered by postfix and procmail, before being served by Dovecot (mail_location = mbox:~/Mail:INBOX=/var/mail/%u) or read by local MUAs, depending on users' preferences.
For people using mostly remote MUAs, it might be interesting to use Dovecot's LDA. I read on http://wiki.dovecot.org/LDA that this is possible using .forward files, however this fails on our system with : file_lock_dotlock() failed with mbox file /var/mail/user: Permission denied (/var/mail is 2775 for root:mail as recently discussed).
Is there a possible fix ? I also read that deliver is not designed to be run setuid root, I guess this also applies to being run setgid mail...
Regards,
Jeremie
On Sat, 2008-03-08 at 15:42 +0100, Jeremie Bouttier wrote:
For people using mostly remote MUAs, it might be interesting to use Dovecot's LDA. I read on http://wiki.dovecot.org/LDA that this is possible using .forward files, however this fails on our system with : file_lock_dotlock() failed with mbox file /var/mail/user: Permission denied (/var/mail is 2775 for root:mail as recently discussed).
Is there a possible fix ? I also read that deliver is not designed to be run setuid root, I guess this also applies to being run setgid mail...
You could set it setgid mail, but that probably allows your users to write to any files/dirs writable by mail group with some symlinks. How about just setting /var/mail 01777?
Timo Sirainen a écrit :
How about just setting /var/mail 01777?
I believe this allows any user to create /var/mail/anotheruser if it does not exist yet. We have several hundred accounts and new ones regularly created, so this is a risk (that could perhaps be mitigated by creating the inbox at the same time as the account ?). Also the Debian policy specifies that /var/mail be 2775, not that it is sacred to me, but since there are other Debian-packaged MDAs/MUAs on the system I'm a bit wary about changing that.
A possibly simple solution (and wishlist item) would be that deliver use an external dotlocking program if needed (dotlockfile, mlock...).
On Mon, 2008-03-10 at 10:05 +0100, Jeremie Bouttier wrote:
Timo Sirainen a écrit :
How about just setting /var/mail 01777?
I believe this allows any user to create /var/mail/anotheruser if it does not exist yet. We have several hundred accounts and new ones regularly created, so this is a risk (that could perhaps be mitigated by creating the inbox at the same time as the account ?). Also the Debian policy specifies that /var/mail be 2775, not that it is sacred to me, but since there are other Debian-packaged MDAs/MUAs on the system I'm a bit wary about changing that.
A possibly simple solution (and wishlist item) would be that deliver use an external dotlocking program if needed (dotlockfile, mlock...).
I did think about external dotlocking program, but that's kind of kludgy as well. At some point I'd want to create a LMTP server and deliver would normally be a simple LMTP client (but optionally deliver directly), so the server could handle all this permission stuff. But it's going to take a while.
So .. I don't think there's going to be a solution for this for a while, at least not from me. How about just delivering mails to ~/mail/inbox and everything would work fine without special privileges?
participants (2)
-
Jeremie Bouttier
-
Timo Sirainen