[Dovecot] v1.2.beta1 released

[Sascha Wilde]

Timo Sirainen <tss at iki.fi> writes:
> On Thu, 2009-02-12 at 13:10 +0100, Sascha Wilde wrote:
>> - cyrus imapd actually tries[1] to implement a variant of this
>>   possibility in that it does not allow to remove the 'a' right from the
>>   owner: 
>
> I implemented this to Dovecot now too.

Good.  :)  

I just gave it a try.  I was a little worried when I saw that I was able
to remove all admin rights from an folder by giving "a" to another user
and let this user first remove "a" from the owner and then from him self
-- fortunately the owner was still able to edit the acls (despite the
missing administrator flag.), so everything is fine:

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready.
lo login bar secret
lo OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH ACL RIGHTS=texk ANNOTATEMORE] Logged in
li list "" "*"
* LIST (\Noselect \HasChildren) "/" "user"
* LIST (\Noselect \HasChildren) "/" "user/foo at example.com"
* LIST (\HasChildren) "/" "INBOX"
* LIST (\HasNoChildren) "/" "user/foo at example.com/test-share"
li OK List completed.
g getacl "user/foo at example.com/test-share"
* ACL "user/foo at example.com/test-share" "foo at example.com" akxeilprwtscd "bar at example.com" akxeilprwtscd
g OK Getacl completed.
s setacl "user/foo at example.com/test-share" "foo at example.com" -a
s OK Setacl complete.
g getacl "user/foo at example.com/test-share"
* ACL "user/foo at example.com/test-share" "foo at example.com" kxeilprwtscd "bar at example.com" akxeilprwtscd
g OK Getacl completed.
s setacl "user/foo at example.com/test-share" "bar at example.com" kxeilprwtscd
s OK Setacl complete.
getacl "user/foo at example.com/test-share"
getacl BAD Error in IMAP command "USER/foo at EXAMPLE.COM/TEST-SHARE": Unknown command.
lo logout
* BYE Logging out
lo OK Logout completed.


* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready.
loginb foo secret
loginb BAD Error in IMAP command received by server.
lo login elf 11
lo OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH ACL RIGHTS=texk ANNOTATEMORE] Logged in
li list "" "*"
* LIST (\HasChildren) "/" "INBOX"
* LIST (\HasNoChildren) "/" "INBOX/test-share"
li OK List completed.
g getacl "INBOX/test-share"
* ACL "INBOX/test-share" "foo at example.com" kxeilprwtscd "bar at example.com" kxeilprwtscd
g OK Getacl completed.
s setacl "INBOX/test-share" "foo at example.com" +a
s OK Setacl complete.
g getacl "INBOX/test-share"
* ACL "INBOX/test-share" "foo at example.com" akxeilprwtscd "bar at example.com" kxeilprwtscd
g OK Getacl completed.


I'm not sure if every detail here is intended, but I think its an good
solution.

>> > I think the owner ACLs are usually in global ACL files, so
>> > it's probably not possible to remove or change it, only add a new
>> > user=x.
>> 
>> I think that it would be best to always map the owners user name to
>> the keyword "owner" and vice versa between the IMAP front end and the
>> acl back end.  This way user=x where x is the owners user name should
>> never appear in an dovecot-acl file.
>
> I did consider this too, but then I thought that it could cause wrong
> results in some special situations. For example if another user's
> mailbox is symlinked to your private namespace and you change your own
> rights, it really should change them and not the owner's.

I haven't thought of that.  I agree that in such cases the mapping would
fail.  However I think there are many setups where such symlink hacks are
not used (and I guess with the new shared user namespaces and IMAP ACL
front end there will be even fewer cases in which such tricks are
useful) -- so maybe this could be configure able?

>> So it boils down to the question
>> if the individual acl-files should take precedence over the global one
>> -- without having checked I assume this decision already has been made.
>
> IIRC in v1.1 mailbox ACL files take precedence, but in v1.2 globals take
> precedence. I changed it because users shouldn't be able to override
> admin's decisions.

I guess it's mainly a question if you see these global ACLs as mere
defaults (in which case it should be possible to overwrite them) or as
an administrative instrument.  I don't really have any opinion which is
more useful...  :)

Once again many thanks for putting all this into 1.2!

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/20090223/7d817385/attachment.bin