Timo Sirainen a écrit :
mail_extra_groups=mail setting is often used insecurely to give Dovecot access to create dotlocks to /var/mail directory. If you don't use mboxes in /var/mail, make sure this setting is cleared. [...] 2a) mbox: Any files/directories under mail group-writable directories can be created/deleted/renamed by symlinking the directory under ~/mail/. For example ln -s /var/mail ~/mail/var, DELETE var/root will happily delete root's mailbox. This I hadn't thought about before.
Not if /var/mail is set sticky, which is the case on all good modern Unix systems:
drwxrwsr-t 2 root mail 4096 2005-12-21 10:19 /var/mail/
mail_privileged_group setting works by keeping the group in process's saved GID while it's not in use and temporarily switching it to effective GID while dotlocks are created. Currently this is done only when:
It's only done for INBOX mbox which doesn't exist under the same location as other mailboxes (so typically under /var/mail).
It's used only after initial dotlock creation try failed with EACCES error.
Too bad... I found mail_extra_groups to be a very handy (and secure) way to handle Dovecot automatic index creation outside user's directory.
I have in dovecot.conf:
mail_extra_groups = mail
mail_location = mbox:~/mail:INBOX=~/mail/INBOX:INDEX=/var/cache/dovecot/indexes/%16Hu/%u
As you can see, all indexes are maintained in /var/cache/dovecot (to be excluded from filesystem quotas), and /var/cache/dovecot/indexes/X directories are pre-created with these perms:
drwxrwsr-t 56 root mail 4096 2008-02-29 03:33 X
This way I don't bother creating index directories for every user, they are created automatically as needed on the first access. I have also a script to expunge old indexes not accessed since a while.
Without mail_extra_groups, I would need to set /var/cache/dovecot/indexes/X directories world-writeable, which is quite less elegant...
-- Ce message a ete verifie par MailScanner pour des virus ou des polluriels et rien de suspect n'a ete trouve.