[Dovecot] acl flag to limit imap_acl based acl changes
Hi all!
I have tried the imap_acl plugin with 1.2.9 today, but was not able to limit acl changes for those mailboxes where acl changes should be forbidden.
http://wiki.dovecot.org/ACL says that "a" or "admin" covers "Administration rights to the mailbox". However, removing "a" from owner acl (using "lr") does not help, the user can still change all acl flags for all users with imap. Write accesses to mails are forbidden as they should.
Is this intended or a bug?
We would like to give all users the ability to use ACLs through IMAP, but the current behaviour endangers our read-only mail archives.
Amon Ott
Dr. Amon Ott - m-privacy GmbH Am Köllnischen Park 1, 10179 Berlin Tel: +49 30 24342334 Fax: +49 30 24342336 Web: http://www.m-privacy.de Handelsregister: Amtsgericht Charlottenburg HRB 84946 Geschäftsführer: Dipl.-Kfm. Holger Maczkowsky, Roman Maczkowsky GnuPG-Key-ID: EA898571
On Mon, 2010-01-25 at 11:57 +0100, Amon Ott wrote:
http://wiki.dovecot.org/ACL says that "a" or "admin" covers "Administration rights to the mailbox". However, removing "a" from owner acl (using "lr") does not help, the user can still change all acl flags for all users with imap. Write accesses to mails are forbidden as they should.
Is this intended or a bug?
Looks like it was intended, to avoid users from accidentally removing admin privileges from their own mailboxes. But there's already other code in SETACL handling that tries to prevent the same thing, so that should be enough.
v2.0 now allows removing admin right manually from dovecot-acl file: http://hg.dovecot.org/dovecot-2.0/rev/667fea930ec3
I probably don't want to do the same change to v1.2, since it might break someone's setup.. Maybe you could use global ACLs to remove the admin right? If it's always the same mailbox name for every user.
On Monday 25 January 2010 wrote Timo Sirainen:
On Mon, 2010-01-25 at 11:57 +0100, Amon Ott wrote:
http://wiki.dovecot.org/ACL says that "a" or "admin" covers "Administration rights to the mailbox". However, removing "a" from owner acl (using "lr") does not help, the user can still change all acl flags for all users with imap. Write accesses to mails are forbidden as they should.
Is this intended or a bug?
Looks like it was intended, to avoid users from accidentally removing admin privileges from their own mailboxes. But there's already other code in SETACL handling that tries to prevent the same thing, so that should be enough.
Yes, that should be. If users edit acl files by hand, they can always change them again.
v2.0 now allows removing admin right manually from dovecot-acl file: http://hg.dovecot.org/dovecot-2.0/rev/667fea930ec3
Thank you for that patch, it also applies cleanly against 1.2.10. Will test that. :)
I probably don't want to do the same change to v1.2, since it might break someone's setup.. Maybe you could use global ACLs to remove the admin right? If it's always the same mailbox name for every user.
It is the inbox among others for some archiving accounts, so a global acl does not work. Could you maybe make it an option in 1.2? Otherwise I will maintain a separate patch in our .deb package here.
Amon Ott
Dr. Amon Ott - m-privacy GmbH Am Köllnischen Park 1, 10179 Berlin Tel: +49 30 24342334 Fax: +49 30 24342336 Web: http://www.m-privacy.de Handelsregister: Amtsgericht Charlottenburg HRB 84946 Geschäftsführer: Dipl.-Kfm. Holger Maczkowsky, Roman Maczkowsky GnuPG-Key-ID: EA898571
On Tuesday 26 January 2010 wrote Amon Ott:
On Monday 25 January 2010 wrote Timo Sirainen:
On Mon, 2010-01-25 at 11:57 +0100, Amon Ott wrote:
http://wiki.dovecot.org/ACL says that "a" or "admin" covers "Administration rights to the mailbox". However, removing "a" from owner acl (using "lr") does not help, the user can still change all acl flags for all users with imap. Write accesses to mails are forbidden as they should.
Is this intended or a bug?
v2.0 now allows removing admin right manually from dovecot-acl file: http://hg.dovecot.org/dovecot-2.0/rev/667fea930ec3
Thank you for that patch, it also applies cleanly against 1.2.10. Will test that. :)
Yes, it works fine now with 1.2.10! Thanks again for the quick solution!
Amon Ott
Dr. Amon Ott - m-privacy GmbH Am Köllnischen Park 1, 10179 Berlin Tel: +49 30 24342334 Fax: +49 30 24342336 Web: http://www.m-privacy.de Handelsregister: Amtsgericht Charlottenburg HRB 84946 Geschäftsführer: Dipl.-Kfm. Holger Maczkowsky, Roman Maczkowsky GnuPG-Key-ID: EA898571
participants (2)
-
Amon Ott
-
Timo Sirainen