Hi *, when a user A shares his INBOX with another user B, the user B can't access its content: User A: g getacl INBOX * ACL INBOX A at example.com lrswipkxtecda B at example.com lrswipkxtecd g OK Completed User B: l list "" "*" * LIST (\Noselect \HasChildren) "/" "user" * LIST (\Noselect \HasChildren) "/" "user/A at example.com" * LIST (\HasChildren) "/" "INBOX" * LIST (\HasNoChildren) "/" "INBOX/Gesendet" * LIST (\HasChildren) "/" "user/A at example.com/foobar" * LIST (\HasNoChildren) "/" "user/A at example.com/INBOX" l OK List completed. s1 select "user/A at example.com" s1 NO [CANNOT] Invalid mailbox name s2 select "user/A at example.com/INBOX" s2 NO [NONEXISTENT] Mailbox doesn't exist: INBOX Actually there are two bugs to observe here: 1) "user/A at example.com" really should be accessible to user B. Why is it listed with "\Noselect"? 2) "user/A at example.com/INBOX" does not exist, so the error message is correct, but why does it appear in the listing in the first place? cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20090304/fd4a72a6/attachment-0002.bin>
Bernhard Herzog
2009-Mar-17 16:12 UTC
[Dovecot] v1.2: can't access other users shared INBOX
On 04.03.2009, Sascha Wilde wrote:> Hi *, > > when a user A shares his INBOX with another user B, the user B can't > access its content: > > User A: > > g getacl INBOX > * ACL INBOX A at example.com lrswipkxtecda B at example.com lrswipkxtecd > g OK Completed > > User B: > > l list "" "*" > * LIST (\Noselect \HasChildren) "/" "user" > * LIST (\Noselect \HasChildren) "/" "user/A at example.com" > * LIST (\HasChildren) "/" "INBOX" > * LIST (\HasNoChildren) "/" "INBOX/Gesendet" > * LIST (\HasChildren) "/" "user/A at example.com/foobar" > * LIST (\HasNoChildren) "/" "user/A at example.com/INBOX" > l OK List completed. > s1 select "user/A at example.com" > s1 NO [CANNOT] Invalid mailbox name > s2 select "user/A at example.com/INBOX" > s2 NO [NONEXISTENT] Mailbox doesn't exist: INBOX > > Actually there are two bugs to observe here: > > 1) "user/A at example.com" really should be accessible to user B. > Why is it listed with "\Noselect"?I'm not sure it should be accessible. This is most likely not A's INBOX. That's the other folder you're trying to access:> 2) "user/A at example.com/INBOX" does not exist, so the error message is > correct, but why does it appear in the listing in the first place?That's A's INBOX, most likely, so it should be accessible. That it's listed but not accessible is AFAICT a combination of two bugs. One is that the INBOX's ACL is used as default, so if B as l-permission in A's INBOX all of A's mailboxes that do not set an ACL for B are listed. The other is that dovecot does not determine B's permissions correctly when it comes to A's INBOX. The first bug is the topic of the other thread ("ACLs are applied recursively to sub mailboxes"). The second comes about as follows, at least for the maildir storage backend: The core of the issue lies again in how acl_backend_vfile_object_init determines the value of the local_path. If the name given to the function is "INBOX", the outcome depends not only on who the owner of the actual storage is, but also on whether the current user is the owner. If the user is the owner, the filename is determined correctly as "dovecot-acl" in the root directory of the user's maildir hierarchy. If the user is not the owner, local_path is set to ".INBOX/dovecot-acl" in the root directory, which is not correct. The reason for this difference are lines 217f in mailbox-list-maildir.c (rev. 5284f45c249a, function maildir_list_get_path): if (strcmp(name, "INBOX") == 0 && _list->set.inbox_path != NULL) return _list->set.inbox_path; i.e. "INBOX" is a special case, but only if inbox_path has been set, and it will be set in maildir_create only if the user is the owner of the mailbox: if (list_set.inbox_path == NULL && strcmp(layout, MAILDIR_PLUSPLUS_DRIVER_NAME) == 0 && (_storage->ns->flags & NAMESPACE_FLAG_INBOX) != 0) { /* Maildir++ INBOX is the Maildir base itself */ list_set.inbox_path = list_set.root_dir; } The solution I'm testing is to simply remove the test for the NAMESPACE_FLAG_INBOX flag (see patch below). So far it seems to work fine. I'm not sure it will have some negative consequences in other parts of dovecot, but I didn't see anything obvious in the code and the inbox_path is conceptually a property of the storage backend and not of the namespace configuration, so whether it's set or not, should probably not depend NAMESPACE_FLAG_INBOX. Regards, Bernhard diff -r 5284f45c249a src/lib-storage/index/maildir/maildir-storage.c --- a/src/lib-storage/index/maildir/maildir-storage.c Sun Mar 15 20:06:45 2009 -0400 +++ b/src/lib-storage/index/maildir/maildir-storage.c Tue Mar 17 16:38:57 2009 +0100 @@ -201,8 +201,7 @@ maildir_create(struct mail_storage *_sto list_set.lock_method = &_storage->lock_method; if (list_set.inbox_path == NULL && - strcmp(layout, MAILDIR_PLUSPLUS_DRIVER_NAME) == 0 && - (_storage->ns->flags & NAMESPACE_FLAG_INBOX) != 0) { + strcmp(layout, MAILDIR_PLUSPLUS_DRIVER_NAME) == 0) { /* Maildir++ INBOX is the Maildir base itself */ list_set.inbox_path = list_set.root_dir; } -- Bernhard Herzog | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://dovecot.org/pipermail/dovecot/attachments/20090317/febf594b/attachment-0002.bin>
On Wed, 2009-03-04 at 17:12 +0100, Sascha Wilde wrote:> 1) "user/A at example.com" really should be accessible to user B.Do you still want that this would point to user's INBOX?> 2) "user/A at example.com/INBOX" does not exist, so the error message is > correct, but why does it appear in the listing in the first place?I committed several fixes related to handling shared INBOXes and also some other mailbox listing bugfixes. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20090402/eb1756b9/attachment-0002.bin>