[Dovecot] Shared mailboxes basics
Hello Timo,
I'm trying to set up shared mailboxes with dovecot-1.2.11/Maildir. I previsouly used public namespaces with 1.1+ to somehow implement them but I'm looking at the real ones now. I've read the Wiki but I'm still confused or not 100% sure about the following (basic) points :
- Namespaces prefixes
My understanding is that a namespace prefix is just an escape mechanism for the client to access the mailboxes this namespace holds. So the real location is _only_ defined by the "location" directive, independently of what the prefix is. So, for example, If you've got :
prefix="foo/bar/" location=maildir:/some/folder/%u
mailboxes are physically in /some/folder/%u, not in /foo/bar/some/folder/%u or something
am I correct ?
- Other Users mailboxes
RFC234 states that shared mailboxes (which they call "Other Users" mailboxes) are "mailboxes from the Personal Namespaces of other users."
Dovecot's Wiki takes as an example :
# User's private mail location. mail_location = maildir:~/Maildir
# You need to create also a private namespace: namespace private { separator = / prefix = #location defaults to mail_location. inbox = yes }
namespace shared { separator = / prefix = shared/%%u/ location = maildir:%%h/Maildir:INDEX=~/Maildir/shared/%%u subscriptions = no list = children }
and states :
"This creates a shared/ namespace under which each user's mailboxes are."
My understanding is that
# User's private mail location. mail_location = maildir:~/Maildir
and
location = maildir:%%h/Maildir
implies that mailboxes in both the private and the shared/ namespace are physically in the same location (under the "$HOME/Maildir" directory of the user who shares his mailbox) . Am I correct ?
I tried the following set up :
namespace private {
separator = /
location = maildir:/courriel/boites/%u:CONTROL=/courriel/meta/%u:INDEX=/var/dovecot-test/indexes/%1u/%u
inbox = yes
hidden = no
list = yes
subscriptions = yes
}
namespace shared { separator = / prefix = "#shared/%%u/" location = maildir:/courriel/boites/%%u:INDEX=/var/dovecot-test/indexes/%1u/%u/shared/%%u subscriptions = no list = yes # will try children later }
the user doveimap has the following mailboxes :
# pwd /courriel/boites # ls -l doveimap total 64 drwx------ 5 doveimap Invites 4096 Oct 23 13:38 .Trash drwxr-xr-x 5 doveimap Invites 4096 Oct 27 17:00 .sous drwxr-xr-x 5 doveimap Invites 4096 Oct 27 17:00 .sous.arbo drwxr-xr-x 5 doveimap Invites 4096 Oct 27 17:00 .sous.arbo.rescence drwx------ 5 doveimap Invites 4096 Oct 23 13:43 .testcopy drwx------ 2 doveimap Invites 4096 Mar 15 17:08 cur drwx------ 2 doveimap Invites 4096 Mar 15 17:07 new drwx------ 2 doveimap Invites 4096 Mar 15 17:07 tmp
I can perform for instance :
- OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN] Dovecot test ready. x login doveimap xxxxxxxx x OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS ACL RIGHTS=texk] Logged in 1 setacl INBOX dovepop rl 1 OK Setacl complete.
But isn't a client like Thunderbird (3.0.3) supposed to
. show me the #shared (even if no one shares mailboxes to me) "folder" (because of list = yes )?
. let me share, let's say the .sous.arbo mailbox ? If yes, how ? Or should I first pre-set some acl files ???
For now, it says : "This is a personnal mail folder. It is not shared."
Thanks
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Thu, Mar 18, 2010 at 05:50:44PM +0100, Thomas Hummel wrote:
But isn't a client like Thunderbird (3.0.3) supposed to
. show me the #shared (even if no one shares mailboxes to me) "folder" (because of list = yes )?
. let me share, let's say the .sous.arbo mailbox ? If yes, how ? Or should I first pre-set some acl files ???
For now, it says : "This is a personnal mail folder. It is not shared."
I made some progress and managed to share a mailbox with my setup but :
a) I wonder if TB even support the SETACL command since I don't see how I can modify an ACL through the TB UI.
b) For things to work, I had to set up loose permissions on the maildirs and the shared-mailbox file. I've read on this list (from the 1.2 beta days) that it is supposed to be easier with virtual user (as opposed to system users) : why ? mailboxes end up being on the filesystem anyway...
In fact, I don't really understand the difference between virtual and system users...Aren't they seen as almost the same for dovecot ?
c) What's weird also is if I put a "dovecot-acl" file in a maildir I want to share, TB does not see it. But if I telnet and issue the SETACL command which end up generating the same dovecot-acl file, TB then sees the shared mailbox...
Timo ?
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Fri, 2010-03-19 at 17:27 +0100, Thomas Hummel wrote:
a) I wonder if TB even support the SETACL command since I don't see how I can modify an ACL through the TB UI.
It doesn't.
b) For things to work, I had to set up loose permissions on the maildirs and the shared-mailbox file. I've read on this list (from the 1.2 beta days) that it is supposed to be easier with virtual user (as opposed to system users) : why ? mailboxes end up being on the filesystem anyway...
In fact, I don't really understand the difference between virtual and system users...Aren't they seen as almost the same for dovecot ?
Yes, they're basically the same. But in that context "easier for virtual users" means "easier if all your users use the same uid", since most people use the same uid for virtual users.. (I don't think wiki confuses these two things?)
c) What's weird also is if I put a "dovecot-acl" file in a maildir I want to share, TB does not see it. But if I telnet and issue the SETACL command which end up generating the same dovecot-acl file, TB then sees the shared mailbox...
Yes, because SETACL updates also the shared-mailbox file, which contains information about what mailboxes are visible to who. Without that, Dovecot would have to look through all users all mailboxes to see if there happens to be any dovecot-acl files that contains rules for current user, which of course would be really slow.
Maybe for v2.0 I could add doveadm acl command to help with these things.
On Fri, Mar 19, 2010 at 09:11:32PM +0200, Timo Sirainen wrote:
Thanks for your answer Timo.
a) I wonder if TB even support the SETACL command since I don't see how I can modify an ACL through the TB UI.
It doesn't.
Ouch! What known UA does support it ?
What's the point of supporting only GETACL ? I guess this means that if users run this client, shared mailboxes have to be managed by an administrator, right ?
Yes, they're basically the same. But in that context "easier for virtual users" means "easier if all your users use the same uid", since most people use the same uid for virtual users.. (I don't think wiki confuses these two things?)
Ok, but I still don't quite get it : if you use the same UID, doesn't this somehow equates giving something like 777 modes in the system user case ? (I mean on an OS level, problems related to such loose permission are the same and, if in 777, permissions are no longer a problem for dovecot) ?
Thanks.
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Fri, 2010-03-19 at 22:09 +0100, Thomas Hummel wrote:
On Fri, Mar 19, 2010 at 09:11:32PM +0200, Timo Sirainen wrote:
Thanks for your answer Timo.
a) I wonder if TB even support the SETACL command since I don't see how I can modify an ACL through the TB UI.
It doesn't.
Ouch! What known UA does support it ?
Mulberry, Kolab, some webmail plugins maybe.
What's the point of supporting only GETACL ?
I guess it just shows nicely what mailboxes are shared.
I guess this means that if users run this client, shared mailboxes have to be managed by an administrator, right ?
Or some custom web interface.
Yes, they're basically the same. But in that context "easier for virtual users" means "easier if all your users use the same uid", since most people use the same uid for virtual users.. (I don't think wiki confuses these two things?)
Ok, but I still don't quite get it : if you use the same UID, doesn't this somehow equates giving something like 777 modes in the system user case ? (I mean on an OS level, problems related to such loose permission are the same and, if in 777, permissions are no longer a problem for dovecot) ?
Pretty much. But 0777 permissions are somewhat worse for security than just giving a single shared uid 0700 permissions. :) So there's nothing magical about virtual users making this easier. It's just that most people wouldn't like using 0777/0666 permissions for all mails..
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 19 Mar 2010, Thomas Hummel wrote:
Ok, but I still don't quite get it : if you use the same UID, doesn't this somehow equates giving something like 777 modes in the system user case ? (I mean on an OS level, problems related to such loose permission are the same and, if in 777, permissions are no longer a problem for dovecot) ?
I tried to hack some magic into Dovecot v1.2, in order to use system users with the default 0700 perms and ACLs.
My idea was to put everybody sharing folders and everybody, who may access shared folders, into the same group "doveshared", then leverage the Unix permissions, that this group may access the folders. So I do not need to use 0777 everywhere.
In fact, I was not able to find a reliable way to get the Unix-permissions right for new mails. Maybe this was because I didn't set ".dovecot-shared" or the Unix-permission of the Maildir base directory right.
I also got fchown() errors for shared mailboxes with write access to non-owners.
Because of this I dropped the idea to use system users with ACLs.
Do you use 0777 Unix perm on all Maildir's and mail folders? Is it working reliable, when mails are dropped with Deliver and APPEND, and when the MUA creates new (sub-)folders?
Regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBS6c3nL+Vh58GPL/cAQIjBgf+IS5agBER7xrbNiHtxe+UPq3Xm4coeGAH DAYsvhATIDoc26knA/NAaCf2ypH+QmddelhIkFhPy+JRLa9qmWd69W9/FRw8x8pe Cpauds/Lwh/iH+apybECB4z5sQ6NZPYZoHJeEidKI/MZeaFnULO2ZDBVcSLK5X14 SmZC2Ji4plz8QPIRa671ZkTmAItViTBho8KTIDny/eJdFX6Acz0L6kLLUek7LrhW 4WpJCPfJ4+lTJE5Zjr7INZiX/2QXW7wp24/sq1j2C9Sd0fZawN3J45a3AKtcx1QW LsfXH1J6FpvaLfNg+uIesYxwuACwbeWoMm0CZLyjgPnfXOGLErECuA== =5dks -----END PGP SIGNATURE-----
On 22.3.2010, at 11.25, Steffen Kaiser wrote:
On Fri, 19 Mar 2010, Thomas Hummel wrote:
Ok, but I still don't quite get it : if you use the same UID, doesn't this somehow equates giving something like 777 modes in the system user case ? (I mean on an OS level, problems related to such loose permission are the same and, if in 777, permissions are no longer a problem for dovecot) ?
I tried to hack some magic into Dovecot v1.2, in order to use system users with the default 0700 perms and ACLs.
My idea was to put everybody sharing folders and everybody, who may access shared folders, into the same group "doveshared", then leverage the Unix permissions, that this group may access the folders. So I do not need to use 0777 everywhere.
Yes, this is what I originally meant with "it's more difficult for system users".
In fact, I was not able to find a reliable way to get the Unix-permissions right for new mails. Maybe this was because I didn't set ".dovecot-shared" or the Unix-permission of the Maildir base directory right.
The new files copy the permissions from the mailbox's root directory (and when mailbox directory is created, its permissions are copied from maildir root). So you should basically do something like:
find /mails -type d | chgrp doveshared find /mails -type d | chmod 0770
I also got fchown() errors for shared mailboxes with write access to non-owners.
Well, this I'm not sure about.. I think fchown() is only called when new files are created. So I guess the process didn't belong to doveshared group? (mail_extra_groups=doveshared would help)
Do you use 0777 Unix perm on all Maildir's and mail folders? Is it working reliable, when mails are dropped with Deliver and APPEND, and when the MUA creates new (sub-)folders?
It should work the same as with 0770, i.e. permissions are copied the same way.
On Mon, Mar 22, 2010 at 11:51:26AM +0200, Timo Sirainen wrote:
My idea was to put everybody sharing folders and everybody, who may access shared folders, into the same group "doveshared", then leverage the Unix permissions, that this group may access the folders. So I do not need to use 0777 everywhere.
Yes, this is what I originally meant with "it's more difficult for system users".
I get it Timo. But you seem to imply that virtual user setup == single shared UID. In such a setup, isn't it mandatory not to give access to the mailboxes by anything else than IMAP. If so, isn't it quite the same as 0777 with a mail_location outside of user's reach (except through IMAP) ?
You maybe would you rely on filesystem acls to have a finer grain access control ?
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Mon, Mar 22, 2010 at 10:25:45AM +0100, Steffen Kaiser wrote:
My idea was to put everybody sharing folders and everybody, who may access shared folders, into the same group "doveshared", then leverage the Unix permissions, that this group may access the folders. So I do not need to use 0777 everywhere.
So basically, you get to the "single UID virtual users" solution but with GID, right ?
Do you mean your maildirs are all in 0770 <user> doveshared ? But it still gives too much permission in general...Especially if your users can access their mailboxes outside of IMAP (NFS, CIFS, ...). How do you deal with that ?
Do you use 0777 Unix perm on all Maildir's and mail folders? Is it working reliable, when mails are dropped with Deliver and APPEND, and when the MUA creates new (sub-)folders?
Well, it was still a theorical question. I haven't really tried anything yet. Also, I'm not using deliver (I know I should) but procmail.
But since for me mail_location is not accessible for users by anything else than IMAP, loose permissions may not be such a critical issue...
Besides, I was thinking of creating as many groups (similar in purpose to your doveshared one) as needs to share a mailbox, if and only if I could somehow restrict (politically I mean) the use of shared mailboxes to "privileged" users (for instance a unit chief and his assistant, ...). Not really scalable I'm afraid though....
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Mon, 2010-03-22 at 11:05 +0100, Thomas Hummel wrote:
On Mon, Mar 22, 2010 at 10:25:45AM +0100, Steffen Kaiser wrote:
My idea was to put everybody sharing folders and everybody, who may access shared folders, into the same group "doveshared", then leverage the Unix permissions, that this group may access the folders. So I do not need to use 0777 everywhere.
Oh, I got mixed you two up in my previous reply :)
So basically, you get to the "single UID virtual users" solution but with GID, right ?
Do you mean your maildirs are all in 0770 <user> doveshared ? But it still gives too much permission in general...Especially if your users can access their mailboxes outside of IMAP (NFS, CIFS, ...). How do you deal with that ?
You don't need to put all users into doveshared group. You just need to set mail_extra_groups=doveshared, so only Dovecot processes have such extra access.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 22 Mar 2010, Timo Sirainen wrote:
their mailboxes outside of IMAP (NFS, CIFS, ...). How do you deal with that ?
I don't have any other access than IMAP.
You don't need to put all users into doveshared group. You just need to set mail_extra_groups=doveshared, so only Dovecot processes have such extra access.
Ah, OK, that's worth trying.
My problems actually were related to the problem that either new messages or new folders were not chgrp()'ed to doveshared. However, my idea was to selectively chgrp shared folders only. I will dig again into this problem eventually, currently I ditched my test server.
Regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBS6dpGL+Vh58GPL/cAQLLXQf/dYbKnm8w+C7rOK2wAyEMxjko/ITp9TjJ 4bFH4cT/lD9KN3Rt6q2tg1f6kTbA9ROGUdAmZ1892eUh83xy58D02nNnjGZ/1Wvj hrcopEqFqWnNSSZAYfuNPcmDLz4tqBT3sknuxavI95hOmb+AMuizC7rWEWpO3SqQ 69P+tqEiqwZeY4fuAfNVnaKU5vDU5I+XloBuVyv/dUVzC2H6oOldSsS5Lwx32aNR 3diXnR1g3g+f/x5AscwoVDhleQGifircOfId2pZMY3r5ZmF1Wl9fI7Psv0rp+B3q R0EKq0j+4PdpSVRNiqhMQsR2UVF0FdoB3dC0fpZdK/OvnTA/VOMGCw== =5Pgl -----END PGP SIGNATURE-----
On Mon, Mar 22, 2010 at 02:47:45PM +0200, Timo Sirainen wrote:
Do you mean your maildirs are all in 0770 <user> doveshared ? But it still gives too much permission in general...Especially if your users can access their mailboxes outside of IMAP (NFS, CIFS, ...). How do you deal with that ?
You don't need to put all users into doveshared group. You just need to set mail_extra_groups=doveshared, so only Dovecot processes have such extra access.
You lost me again : what's the use of the userdb " acl_groups" extra-field then ?
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 22 Mar 2010, Thomas Hummel wrote:
On Mon, Mar 22, 2010 at 02:47:45PM +0200, Timo Sirainen wrote:
Do you mean your maildirs are all in 0770 <user> doveshared ? But it still gives too much permission in general...Especially if your users can access their mailboxes outside of IMAP (NFS, CIFS, ...). How do you deal with that ?
You don't need to put all users into doveshared group. You just need to set mail_extra_groups=doveshared, so only Dovecot processes have such extra access.
You lost me again : what's the use of the userdb " acl_groups" extra-field then ?
acl_groups is for the logical "ACL"s in Dovecot and is just a name, it relates to nothing in the Unix world.
mail_extra_groups= is an Unix group, the Dovecot processes gets as secondary group.
Regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBS6dy67+Vh58GPL/cAQJGtQgAttzmmE6hOamBLfedG1IJNJaHrxXbYnvZ 3lRsg+h0pNzzRG21Pvcu2zsfYkT6Y8FZbR9yB57cE1qQ3kPyk+ZztN2d6UAozbVL SDFG+tMpKQqHRR4zaj9zLUpd8SE81Zceo0tga8zVTiGtAWFrTu9vWuzQP9HsrWRO lssxuvbGt3Vq4iAcR2tP3cZXCJP/jlKW+rSbbgGVTz1tJ6DvTkHL47CsZdwRE1Qk usf7hNbDtoBLzUrQcoWFwBNSrD27JOPksEP2ulAf9UQFed9MJ7ekB6EYnVuxgtO9 sJ6btiWlx595x3OukGoet0EZF68x9PdwOvPZbrsO6U1hxcr+H8wQxg== =ElAf -----END PGP SIGNATURE-----
On Mon, 2010-03-22 at 14:34 +0100, Thomas Hummel wrote:
You lost me again : what's the use of the userdb " acl_groups" extra-field then ?
That only adds user to given ACL groups for ACL plugin's checks. ACL plugin deals only with virtual permissions, acl_groups has nothing to do with filesystem permissions. If user doesn't already have enough filesystem permissions to access some mailbox, ACL plugin won't grant them either.
On Mon, Mar 22, 2010 at 03:40:23PM +0200, Timo Sirainen wrote:
On Mon, 2010-03-22 at 14:34 +0100, Thomas Hummel wrote:
You lost me again : what's the use of the userdb " acl_groups" extra-field then ?
That only adds user to given ACL groups for ACL plugin's checks. ACL plugin deals only with virtual permissions, acl_groups has nothing to do with filesystem permissions. If user doesn't already have enough filesystem permissions to access some mailbox, ACL plugin won't grant them either.
Ok.
So basically, independently of ACL groups, the idea is to
. chgrp all maildirs to some unix group (doveshared)
. chmod 0770 those maildirs
. add that group to mail_extra_groups
. so dovecot would be able to access any shared mailboxes (from anyone to anyone)
correct ?
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Mon, 2010-03-22 at 14:56 +0100, Thomas Hummel wrote:
So basically, independently of ACL groups, the idea is to
. chgrp all maildirs to some unix group (doveshared)
. chmod 0770 those maildirs
. add that group to mail_extra_groups
. so dovecot would be able to access any shared mailboxes (from anyone to anyone)
correct ?
Yes.
On Mon, Mar 22, 2010 at 03:59:02PM +0200, Timo Sirainen wrote:
Yes.
Ok, I was complicating things then : I was using the "system_groups_user" extra-field and a secondary "doveshared" unix group.
But the question now is when to use mail_extra_groups and when to use the "system_groups_user" extra-field ? As I see it now, system_groups_user gives finer grain control since it's on a user basis.
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Fri, Mar 19, 2010 at 09:11:32PM +0200, Timo Sirainen wrote:
Yes, because SETACL updates also the shared-mailbox file, which contains information about what mailboxes are visible to who. Without that, Dovecot would have to look through all users all mailboxes to see if there happens to be any dovecot-acl files that contains rules for current user, which of course would be really slow.
Get it. So I guess the recommended method to "make the share mailboxes visible" is to talk IMAP (through telnet for instance) and not trying to suppose anything about the shared-mailbox file format and try to hack it directly, right ?
-- Thomas Hummel | Institut Pasteur hummel@pasteur.fr | Pôle informatique - systèmes et réseau
On Fri, 2010-03-19 at 22:14 +0100, Thomas Hummel wrote:
Get it. So I guess the recommended method to "make the share mailboxes visible" is to talk IMAP (through telnet for instance) and not trying to suppose anything about the shared-mailbox file format and try to hack it directly, right ?
Right. Note that you could also do things like:
printf "1 setacl blah\n2 logout\n" | dovecot --exec-mail imap
(assuming environment is setup properly, USER=username being the most important)
participants (3)
-
Steffen Kaiser
-
Thomas Hummel
-
Timo Sirainen