[Dovecot] ACLs are applied recursively to sub mailboxes
Hi *,
The problem is most noticeable when a user shares his INBOX[0][1] with others:
User A sets his INBOX acls to "eilprwtsd"
Now User B can see _all_ sub mailboxes and sub sub [...] mailboxes and their contents of User A:
User A: g getacl INBOX
- ACL "INBOX" "A@example.com" akxeilprwtscd "B@example.com" eilprwtsd "A@example.com" lrwstipekxacd g OK Getacl completed. g getacl INBOX/foobar
- ACL "INBOX/foobar" "1@aztec.intevation.de" lrwstipekxacd
User B: l list "" "*"
- LIST (\Noselect \HasChildren) "/" "user"
- LIST (\Noselect \HasChildren) "/" "user/1@aztec.intevation.de"
- LIST (\HasChildren) "/" "INBOX"
- LIST (\HasNoChildren) "/" "INBOX/Gesendet"
- LIST (\HasChildren) "/" "user/1@aztec.intevation.de/foobar"
- LIST (\HasNoChildren) "/" "user/1@aztec.intevation.de/foobar/barbaaz"
- LIST (\HasNoChildren) "/" "user/1@aztec.intevation.de/INBOX" l OK List completed.
The RfC is not to verbose on this topic of scope, but I think the following excerpt from RfC4314:
- Access Control
[...]
An access control list is a set of <access identifier,rights>
pairs. An ACL applies to a mailbox name.indicates that ACLs are only valid for individual mailboxes (name) and not for sub mailboxes.
cheers sascha
[0] Yes, there are really actual users wanting to do this. [1] There is actually another bug in this context I'll report in my next mail...
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
Sascha Wilde wilde@intevation.de writes:
Ooops some search and replace missing, the example should read:
User A: g getacl INBOX
- ACL "INBOX" "A@example.com" akxeilprwtscd "B@example.com" eilprwtsd "A@example.com" lrwstipekxacd g OK Getacl completed. g getacl INBOX/foobar
- ACL "INBOX/foobar" "A@example.com" lrwstipekxacd
User B: l list "" "*"
- LIST (\Noselect \HasChildren) "/" "user"
- LIST (\Noselect \HasChildren) "/" "user/A@example.com"
- LIST (\HasChildren) "/" "INBOX"
- LIST (\HasNoChildren) "/" "INBOX/Gesendet"
- LIST (\HasChildren) "/" "user/A@example.com/foobar"
- LIST (\HasNoChildren) "/" "user/A@example.com/foobar/barbaaz"
- LIST (\HasNoChildren) "/" "user/A@example.com/INBOX" l OK List completed.
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
On Wed, 2009-03-04 at 17:01 +0100, Sascha Wilde wrote:
Hi *,
The problem is most noticeable when a user shares his INBOX[0][1] with others:
User A sets his INBOX acls to "eilprwtsd"
Now User B can see _all_ sub mailboxes and sub sub [...] mailboxes and their contents of User A:
That shouldn't happen. There's no code for doing recursive ACLs. Sounds more like a bug somewhere. I'll check it later.
- ACL "INBOX" "A@example.com" akxeilprwtscd "B@example.com" eilprwtsd "A@example.com" lrwstipekxacd
A@example.com is there twice?..
- LIST (\HasChildren) "/" "user/1@aztec.intevation.de/foobar"
How does user B see this mailbox's ACLs? Is the mailbox also selectable?
Timo Sirainen tss@iki.fi writes:
On Wed, 2009-03-04 at 17:01 +0100, Sascha Wilde wrote:
Hi *,
The problem is most noticeable when a user shares his INBOX[0][1] with others:
User A sets his INBOX acls to "eilprwtsd"
Now User B can see _all_ sub mailboxes and sub sub [...] mailboxes and their contents of User A:
That shouldn't happen. There's no code for doing recursive ACLs. Sounds more like a bug somewhere. I'll check it later.
Thanks.
- ACL "INBOX" "A@example.com" akxeilprwtscd "B@example.com" eilprwtsd "A@example.com" lrwstipekxacd
A@example.com is there twice?..
Oh, haven't noticed that, but yes its actually there twice. The dovecot-acl file contains: user=A@example.com akxeilprwts user=B@example.com eilprwts
- LIST (\HasChildren) "/" "user/1@aztec.intevation.de/foobar"
How does user B see this mailbox's ACLs? Is the mailbox also selectable?
Well good question -- unfortunately I can't tell: both getacl and myrights on "user/1@aztec.intevation.de/foobar" make the imap process die on SIGV... :-(
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
Sascha Wilde wilde@intevation.de writes:
Timo Sirainen tss@iki.fi writes:
On Wed, 2009-03-04 at 17:01 +0100, Sascha Wilde wrote:
- LIST (\HasChildren) "/" "user/1@aztec.intevation.de/foobar"
[...] Is the mailbox also selectable?
Oh, missed to answer that question: yes, it is selectable and the contents is actually accessible from an ordinary imap client.
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
Timo Sirainen tss@iki.fi writes:
On Wed, 2009-03-04 at 17:01 +0100, Sascha Wilde wrote:
Hi *,
The problem is most noticeable when a user shares his INBOX[0][1] with others:
User A sets his INBOX acls to "eilprwtsd"
Now User B can see _all_ sub mailboxes and sub sub [...] mailboxes and their contents of User A:
That shouldn't happen. There's no code for doing recursive ACLs. Sounds more like a bug somewhere. I'll check it later.
Hi, have you already found the time to have a look at it? Otherwise it might be a good idea if we (== any of the Kolab people at Intevation) had a look at some of the ACL problems I reported?
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
On Mon, 2009-03-09 at 16:46 +0100, Sascha Wilde wrote:
That shouldn't happen. There's no code for doing recursive ACLs. Sounds more like a bug somewhere. I'll check it later.
Hi, have you already found the time to have a look at it? Otherwise it might be a good idea if we (== any of the Kolab people at Intevation) had a look at some of the ACL problems I reported?
I've been a bit busy (or lazy) recently and I'm not focusing on trying to get the new dbox code working. I'll look at the ACL bugs at some point, but you can probably get them fixed sooner if you do it yourself.
On 10.03.2009, Timo Sirainen wrote:
I've been a bit busy (or lazy) recently and I'm not focusing on trying to get the new dbox code working. I'll look at the ACL bugs at some point, but you can probably get them fixed sooner if you do it yourself.
I'm going to look into this.
Bernhard
-- 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
On 13.03.2009, Bernhard Herzog wrote:
On 10.03.2009, Timo Sirainen wrote:
I've been a bit busy (or lazy) recently and I'm not focusing on trying to get the new dbox code working. I'll look at the ACL bugs at some point, but you can probably get them fixed sooner if you do it yourself.
I'm going to look into this.
OK. So far I've concentrated on the problem that ACLs set on the INBOX are applied to all children of INBOX. E.g. if you have users frodo and bilbo, and frodo does x SETACL "INBOX" "bilbo" lsr then bilbo will not only see frodo's INBOX as intended, but also all subfolders. More precisely the ACL of the INBOX is used for all folders that do not have their own ACL settings for bilbo.
Here's what I've found out so far:
The reason for the behavior is an aclobj with name "" which takes its actual rights from the dovecot-acl file in the other user's INBOX. That aclobj is used for the default ACLs used for mailboxes with ACL entry for the user and for non-owners should normally be no rights at all and not taken from the ACL of the INBOX.
That pathological aclobj is created in acl_backend_init:
backend->default_aclobj = acl_object_init_from_name(backend, NULL, "").
acl_object_init_from_name calls acl_backend_vfile_object_init, which sets the
aclobj's local_path. In this particular case -- name == "" and storage ==
NULL -- local_path will become the concatenation of the directory name
returned by
mailbox_list_get_path(_backend->list, NULL,
MAILBOX_LIST_PATH_TYPE_DIR)
and "/dovecot-acl", which at least in the case of maildir is in the owner's
INBOX directory. Later, when the user lists mailboxes, this file is actually
read to determine the rights.
That explains the observed behavior. I'm not sure yet how to fix it. I'll look into that next.
Bernhard
-- 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
On Mon, 2009-03-16 at 20:33 +0100, Bernhard Herzog wrote:
That pathological aclobj is created in acl_backend_init: backend->default_aclobj = acl_object_init_from_name(backend, NULL, "").
acl_object_init_from_name calls acl_backend_vfile_object_init, which sets the aclobj's local_path. In this particular case -- name == "" and storage == NULL -- local_path will become the concatenation of the directory name returned by mailbox_list_get_path(_backend->list, NULL, MAILBOX_LIST_PATH_TYPE_DIR) and "/dovecot-acl", which at least in the case of maildir is in the owner's INBOX directory. Later, when the user lists mailboxes, this file is actually read to determine the rights.That explains the observed behavior. I'm not sure yet how to fix it. I'll look into that next.
Hmm. I'm not sure if there's a reason for the existence of the default ACLs being looked up from dovecot-acl file. I think the initial fix could be to simply not do that. If someone really wants to have different default ACLs they could perhaps be stored in a file with different name.
On 16.03.2009, Timo Sirainen wrote:
On Mon, 2009-03-16 at 20:33 +0100, Bernhard Herzog wrote:
That pathological aclobj is created in acl_backend_init: backend->default_aclobj = acl_object_init_from_name(backend, NULL, ""). acl_object_init_from_name calls acl_backend_vfile_object_init, which sets the aclobj's local_path. In this particular case -- name == "" and storage == NULL -- local_path will become the concatenation of the directory name returned by mailbox_list_get_path(_backend->list, NULL, MAILBOX_LIST_PATH_TYPE_DIR) and "/dovecot-acl", which at least in the case of maildir is in the owner's INBOX directory. Later, when the user lists mailboxes, this file is actually read to determine the rights. [...] Hmm. I'm not sure if there's a reason for the existence of the default ACLs being looked up from dovecot-acl file. I think the initial fix could be to simply not do that. If someone really wants to have different default ACLs they could perhaps be stored in a file with different name.
As an attempt to fix the problem, I modified acl_backend_vfile_object_init so that local_path will be set to NULL in the default aclobj (see patch below). My tests so far, show that it works as expected. The ACL of the INBOX is no longer the default ACL. Regards, Bernhard diff -r 5284f45c249a src/plugins/acl/acl-backend-vfile.c --- a/src/plugins/acl/acl-backend-vfile.c Sun Mar 15 20:06:45 2009 -0400 +++ b/src/plugins/acl/acl-backend-vfile.c Tue Mar 17 14:42:58 2009 +0100 @@ -152,8 +152,7 @@ acl_backend_vfile_object_init(struct acl if (storage == NULL) { /* the default ACL for mailbox list */ - dir = mailbox_list_get_path(_backend->list, NULL, - MAILBOX_LIST_PATH_TYPE_DIR); + dir = NULL; } else { dir = acl_backend_vfile_get_local_dir(storage, name); } -- 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
On Mar 16, 2009, at 4:12 PM, Timo Sirainen wrote:
Hmm. I'm not sure if there's a reason for the existence of the default ACLs being looked up from dovecot-acl file. I think the initial fix could be to simply not do that. If someone really wants to have different default ACLs they could perhaps be stored in a file with different name.
Actually I remembered now: With global ACLs it allowed having .DEFAULT
file describing the default ACLs, which could be used to e.g. allow
some specific user access to everyone's maiboxes. So I guess the right
fix would be to keep this behavior but not to look up INBOX's dovecot-
acl file.
On Mar 17, 2009, at 12:08 PM, Timo Sirainen wrote:
On Mar 16, 2009, at 4:12 PM, Timo Sirainen wrote:
Hmm. I'm not sure if there's a reason for the existence of the
default ACLs being looked up from dovecot-acl file. I think the initial fix could be to simply not do that. If someone really wants to have different default ACLs they could perhaps be stored in a file with different name.Actually I remembered now: With global ACLs it allowed
having .DEFAULT file describing the default ACLs, which could be
used to e.g. allow some specific user access to everyone's maiboxes.
So I guess the right fix would be to keep this behavior but not to
look up INBOX's dovecot-acl file.
Although if user creates new ACLs tat probably causes overriding
the .DEFAULT file, so this is a bit pointless. I guess it would be
nice to have "global ACLs that apply to all mailboxes regardless of
whether they contain their own ACLs", but I guess it can wait until
someone actually requests such feature :)
participants (3)
-
Bernhard Herzog
-
Sascha Wilde
-
Timo Sirainen