[Dovecot] Deliver Root Setuid
Hi, I just configured my Postfix installation to deliver via Dovecot LDA. But because I use separate uids for virtual domains I had to set deliver to be setuid root. Altough I find this as frequent answer to this problem with deliver LDA I am not a 100% sure - basically because I try to avoid root setuids as much as I can.
What should be better solution - to have all mailboxes with one owner or this setuid binary?
My main reason for separate uids was filesystem quotas for whole domain. But my mail partition resides on XFS so I can do the same with directory quotas and I also noticed changes in quotas which should be also per domain in some next release or with patch.
Thanks for any advice and also thanks for all great work on Dovecot.
LáďaOn Sun, 2006-12-03 at 18:23 +0100, Láďa wrote:
Hi, I just configured my Postfix installation to deliver via Dovecot LDA. But because I use separate uids for virtual domains I had to set deliver to be setuid root. Altough I find this as frequent answer to this problem with deliver LDA I am not a 100% sure – basically because I try to avoid root setuids as much as I can.
What should be better solution – to have all mailboxes with one owner or this setuid binary?
I don't think there's a better way right now. I'll probably change deliver at some point so that you can run it directly under Postfix's master instead of going through pipe. Then it can be started as root.
My main reason for separate uids was filesystem quotas for whole domain. But my mail partition resides on XFS so I can do the same with directory quotas and I also noticed changes in quotas which should be also per domain in some next release or with patch.
I guess you could also use virtual quota (eg. maildir++ quota).
On Sun, 2006-12-03 at 19:27 +0200, Timo Sirainen wrote:
My main reason for separate uids was filesystem quotas for whole domain. But my mail partition resides on XFS so I can do the same with directory quotas and I also noticed changes in quotas which should be also per domain in some next release or with patch.
I guess you could also use virtual quota (eg. maildir++ quota).
Should have thought a bit more before replying. :)
If you want domain quotas then.. well, Maildir++ quota won't work right now.
You could use dictionary quotas (== keep the quota in MySQL), but it has one problem: It doesn't support recalculating quota yet, so making it work for existing users could be problematic. Hmm. Maybe I should finally implement that, so that it would actually be usable..
On 12/3/06, Timo Sirainen tss@iki.fi wrote:
On Sun, 2006-12-03 at 19:27 +0200, Timo Sirainen wrote:
My main reason for separate uids was filesystem quotas for whole domain. But my mail partition resides on XFS so I can do the same with directory quotas and I also noticed changes in quotas which should be also per domain in some next release or with patch.
I guess you could also use virtual quota (eg. maildir++ quota).
Should have thought a bit more before replying. :)
If you want domain quotas then.. well, Maildir++ quota won't work right now.
You could use dictionary quotas (== keep the quota in MySQL), but it has one problem: It doesn't support recalculating quota yet, so making it work for existing users could be problematic. Hmm. Maybe I should finally implement that, so that it would actually be usable..
You mean something like: # quota = dict:user::/etc/dovecot-user-quota.conf # quota2 = dict:domain:%d:/etc/dovecot-domain-quota.conf what can be found in the wiki (but not in the main sources)? I think I can stick with XFS quotas for a while. Not so nice solution but still usable.
I think I can stick with XFS quotas for a while. Not so nice solution but still usable.
If you currently use XFS group quotas for domain-based quotas, you can make this work with Dovecot using a patched filesystem backend. It will enable reporting of group filesystem quotas (in addition to using inode filesystem quotas for message number quotas).
I have been using this patch in a production environment (Linux with ext3) since June, and it has been working perfectly for me. I last updated this patch for rc7, and it probably does not apply cleanly to recent rc versions. I'll update the patch again once 1.0 comes out, but doubt I'll have time to do it before then. You can probably use the patched rc7 version of quota-fs.c with rc15 without problems. I attached both the patch and the patched quota-fs.c files to the email previously.
http://www.dovecot.org/list/dovecot/2006-August/015662.html
Scott
On Sun, 2006-12-03 at 18:52 +0100, Ladislav Durchánek wrote:
On 12/3/06, Timo Sirainen tss@iki.fi wrote:
On Sun, 2006-12-03 at 19:27 +0200, Timo Sirainen wrote:
My main reason for separate uids was filesystem quotas for whole domain. But my mail partition resides on XFS so I can do the same with directory quotas and I also noticed changes in quotas which should be also per domain in some next release or with patch.
I guess you could also use virtual quota (eg. maildir++ quota).
Should have thought a bit more before replying. :)
If you want domain quotas then.. well, Maildir++ quota won't work right now.
You could use dictionary quotas (== keep the quota in MySQL), but it has one problem: It doesn't support recalculating quota yet, so making it work for existing users could be problematic. Hmm. Maybe I should finally implement that, so that it would actually be usable..
Implemented it. But it doesn't actually help with domain quotas, since users can't access each others mails to count the domain quota..
You mean something like: # quota = dict:user::/etc/dovecot-user-quota.conf # quota2 = dict:domain:%d:/etc/dovecot-domain-quota.conf what can be found in the wiki (but not in the main sources)?
Yea. Actually that won't really work, but this would:
plugin { # "domain" is the quota root name. Could be anything. # %d means that the quota "key" is %d, ie. domain. Default is %u. # proxy::domain_quota is the dictionary URI quota = dict:domain:%d:proxy::quota_domain }
dict { quota_domain = mysql:/usr/local/etc/dovecot-quota-domain.conf }
Anyway you'll need to apply http://dovecot.org/patches/quota-rewrite.diff if you plan on doing any of this.
On 12/3/06, Timo Sirainen tss@iki.fi wrote:
On Sun, 2006-12-03 at 18:52 +0100, Ladislav Durchánek wrote:
On 12/3/06, Timo Sirainen tss@iki.fi wrote:
On Sun, 2006-12-03 at 19:27 +0200, Timo Sirainen wrote:
My main reason for separate uids was filesystem quotas for whole domain. But my mail partition resides on XFS so I can do the same with directory quotas and I also noticed changes in quotas which should be also per domain in some next release or with patch.
I guess you could also use virtual quota (eg. maildir++ quota).
Should have thought a bit more before replying. :)
If you want domain quotas then.. well, Maildir++ quota won't work right now.
You could use dictionary quotas (== keep the quota in MySQL), but it has one problem: It doesn't support recalculating quota yet, so making it work for existing users could be problematic. Hmm. Maybe I should finally implement that, so that it would actually be usable..
Implemented it. But it doesn't actually help with domain quotas, since users can't access each others mails to count the domain quota..
You rock :-)
You mean something like: # quota = dict:user::/etc/dovecot-user-quota.conf # quota2 = dict:domain:%d:/etc/dovecot-domain-quota.conf what can be found in the wiki (but not in the main sources)?
Yea. Actually that won't really work, but this would:
plugin { # "domain" is the quota root name. Could be anything. # %d means that the quota "key" is %d, ie. domain. Default is %u. # proxy::domain_quota is the dictionary URI quota = dict:domain:%d:proxy::quota_domain }
dict { quota_domain = mysql:/usr/local/etc/dovecot-quota-domain.conf }
Anyway you'll need to apply http://dovecot.org/patches/quota-rewrite.diff if you plan on doing any of this.
When is this supposed to get to the main tree, in some 1.1beta? I am not in hurry - just asking :-)
On Sun, 2006-12-03 at 20:16 +0100, Ladislav Durchánek wrote:
Anyway you'll need to apply http://dovecot.org/patches/quota-rewrite.diff if you plan on doing any of this.
When is this supposed to get to the main tree, in some 1.1beta? I am not in hurry - just asking :-)
It's in CVS HEAD already. So after I release v1.0 I'll also then release v1.1 (unstable series) at the same time.
participants (4)
-
Ladislav Durchánek
-
Láďa
-
Scott Alter
-
Timo Sirainen