Hello,
I am working on implementing support for the RFC4314 ACL management commands and responses in the ACL plugin included with dovecot 1.1.2. (I verified the error persists with 1.1.3 though.) While the described objective is still in the works, I have stumbled upon what I believe to be a critical issue with the handling of negative rights in the present ACL plugin - to be precise, the cache component of it handles them in the exact same way as it does positive rights, thus granting rather than retracting the individual privileges.
To fix this, go to src/plugins/acl/acl-cache.c:391. The line and the one following it should read p[j] |= obj_cache->my_neg_rights[i]->mask[j]; Replace that to read p[j] &= ~obj_cache->my_neg_rights[i]->mask[j];
I hope this information is useful.
Regards, M. Soloviev
On Mon, 2008-09-08 at 15:14 +0200, Matvey Soloviev wrote:
Hello,
I am working on implementing support for the RFC4314 ACL management commands and responses in the ACL plugin included with dovecot 1.1.2.
Sounds great. :) Did you also notice my "Initial support for shared mailboxes" message from yesterday?
(I verified the error persists with 1.1.3 though.) While the described objective is still in the works, I have stumbled upon what I believe to be a critical issue with the handling of negative rights in the present ACL plugin - to be precise, the cache component of it handles them in the exact same way as it does positive rights, thus granting rather than retracting the individual privileges.
I think the ACL plugin has currently been used only for some very basic configurations and it's not very well tested. I guess test cases would be nice, but the framework for easily doing that is still missing. Once you've implemented support for the IMAP ACL commands I could add test cases to imaptest (http://imapwiki.org/ImapTest).
To fix this, go to src/plugins/acl/acl-cache.c:391. The line and the one following it should read p[j] |= obj_cache->my_neg_rights[i]->mask[j]; Replace that to read p[j] &= ~obj_cache->my_neg_rights[i]->mask[j];
Thanks, fixed in v1.[012] code trees.
Did you also notice my "Initial support for shared mailboxes" message from yesterday? No, unfortunately I didn't; I only joined the mailing list on the day I sent this message. It sounds like it could be relevant to the topic though; could you provide me with a breakdown of what it is about?
not very well tested Well, I'll be inevitably running some stress tests myself, but yes, including it in the official test chain once it is done would be a fundamentally good thing to do.
Would a facility to modify global ACLs through IMAP commands be required or of any use at all? From what I gather, nothing like that is mentioned anywhere in the RFC. As it is now, I am having the writing commands influence only the referenced mailboxes' local ACLs - however, should global ACLs be present, this is bound to result in somewhat irrational-seeming behaviour - should I go through with my current approach of storing the ACL data as present in acl_object_vfile.rights into the local dovecot-acl file, global ACLs would, on the one hand, wind up being copied into it - on the other hand, from the client's perspective, the ACLs defined by the global file would appear to be irremovable. What should I do about this?
Regards, Matvey
On Thu, 2008-09-11 at 18:18 +0200, Matvey Soloviev wrote:
Did you also notice my "Initial support for shared mailboxes" message from yesterday? No, unfortunately I didn't; I only joined the mailing list on the day I sent this message. It sounds like it could be relevant to the topic though; could you provide me with a breakdown of what it is about?
http://dovecot.org/list/dovecot/2008-September/033464.html - basically the ability to access other users' mailboxes.
Would a facility to modify global ACLs through IMAP commands be required or of any use at all?
I'd say it wouldn't be of any use.
From what I gather, nothing like that is mentioned anywhere in the RFC. As it is now, I am having the writing commands influence only the referenced mailboxes' local ACLs - however, should global ACLs be present, this is bound to result in somewhat irrational-seeming behaviour - should I go through with my current approach of storing the ACL data as present in acl_object_vfile.rights into the local dovecot-acl file, global ACLs would, on the one hand, wind up being copied into it - on the other hand, from the client's perspective, the ACLs defined by the global file would appear to be irremovable. What should I do about this?
Hmm. Let's think about the use cases for global ACLs:
ACLs that actually restrict what user can do, for example force the mailbox to be read-only. These would also remove the admin-right from the user and this wouldn't be an issue.
ACLs that allow a special account to access the mailbox (e.g. backup, voicemail, ..). A user must not be able to remove these rights.
Default ACLs for some mailbox that tries to prevent user from doing something accidentally, but allows a user to override the behavior by overriding the ACL.
I don't know if anyone uses 3) for anything. I'm not really even sure what it could be used for really. For 1) and 2) I'd actually argue that the user shouldn't even see the global ACLs (and certainly not override them), only how they affect the user's rights. 2) might actually need to be some kind of a "global for all mailbxes" ACL, at least for backup.
So I'm thinking that if possible don't let the user see or override the global ACLs. If that's too much work just ignore the problem for now and assume the user won't have admin-right to such mailboxes anyway.
On 9/8/2008, Matvey Soloviev (blackhole89@gmail.com) wrote:
Hello,
I am working on implementing support for the RFC4314 ACL management commands and responses in the ACL plugin included with dovecot 1.1.2.
Yay! Thanks Matvey!
Dovecot is just getting better and better, and soon will eclipse cyrus in features and performance - while it already is *vastly* easier to install/configure.
--
Best regards,
Charles
"Matvey Soloviev" blackhole89@gmail.com writes:
I am working on implementing support for the RFC4314 ACL management commands and responses in the ACL plugin included with dovecot [...]
Matvey finished a first version of the IMAP front end to the ACL plugin.
You can find the changes for dovecot 1.1.3 here: http://hg.intevation.org/kolab/dovecot-1.1_acl-branch/ and as we decided to move on to 1.2, here: http://hg.intevation.org/kolab/dovecot-1.2_acl-branch/
As of writing this the changes for 1.1.3 and 1.2 are the same (but the 1.2 version isn't really tested yet).
cheers sascha
Sascha Wilde OpenPGP key: 4BB86568 Intevation GmbH, Osnabrück http://www.intevation.de/~wilde/ Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/ Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
On Oct 1, 2008, at 12:57 PM, Sascha Wilde wrote:
"Matvey Soloviev" blackhole89@gmail.com writes:
I am working on implementing support for the RFC4314 ACL management
commands and responses in the ACL plugin included with dovecot [...]Matvey finished a first version of the IMAP front end to the ACL
plugin.You can find the changes for dovecot 1.1.3 here: http://hg.intevation.org/kolab/dovecot-1.1_acl-branch/ and as we decided to move on to 1.2, here: http://hg.intevation.org/kolab/dovecot-1.2_acl-branch/
As of writing this the changes for 1.1.3 and 1.2 are the same (but the 1.2 version isn't really tested yet).
A did a quick look, a few comments:
if(strchr(box,' ')) str_append_c(str,'\"'); str_append(str,box); if(strchr(box,' ')) str_append_c(str,'\"');
Use instead imap_quote_append_string(str, box, FALSE);
The IMAP commands should be in a new imap-acl plugin similar to quota/ imap-quota so that the ACL plugin is usable in deliver.
Write the ACL file by creating a temp file and renaming it over the
original file. That way if the process crashes the ACLs won't ever get
lost. Also you don't then need to read-lock the file and it'll work
nicely with all NFS setups. Easiest way to do this is:
- file_dotlock_open()
- write to the file
- fsync() the file
- file_dotlock_replace()
Timo Sirainen tss@iki.fi writes:
On Oct 1, 2008, at 12:57 PM, Sascha Wilde wrote:
"Matvey Soloviev" blackhole89@gmail.com writes: Matvey finished a first version of the IMAP front end to the ACL plugin.
You can find the changes for dovecot 1.1.3 here: http://hg.intevation.org/kolab/dovecot-1.1_acl-branch/ and as we decided to move on to 1.2, here: http://hg.intevation.org/kolab/dovecot-1.2_acl-branch/ [...] A did a quick look, a few comments:
Thanks for your comments. I forwarded them to Matvey, asking him to include them in his changes.
cheers sascha
Sascha Wilde OpenPGP key: 4BB86568 Intevation GmbH, Osnabrück http://www.intevation.de/~wilde/ Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/ Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
participants (4)
-
Charles Marcus
-
Matvey Soloviev
-
Sascha Wilde
-
Timo Sirainen