ACL handling bugs in v1.2.8+ and v2.0
I thought I'd write one mail about this, rather than duplicate the whole thing to both v1.2.15 and v2.0.5 release announcements. So, ever since this commit: 2009-11-10 Timo Sirainen <tss@iki.fi> * src/plugins/acl/acl-backend-vfile.c: acl: Merge group rights if user belongs to more than one. [76ff6831c9ae] The ACLs were being merged, rather than fully replaced, a bit too often. Since this is about merging, the problem could have happened only when using more than one entry in the ACL file. The main problems created by this were: a) If admin wanted to remove some rights from mailboxes in user's private namespace (e.g. symlinked shared mailboxes), they may not have gotten removed. b) When mixing up multiple ACL entries, such as groups/users the more specific entry may not have replaced the previous entry (e.g. group-override may not have worked as expected). The bug happened when two or more ACL entries of same "type" existed. The first entry was handled correctly, but the next ones may have only been adding ACLs rather than replacing them. For example if you had the following ACL file: group=people lrwi user=foo lr user=bar lr So basically everyone in "people" group should have "lrwi" rights, but foo and bar users should have only "lr" rights. If foo and bar didn't belong to people group, everything would work as expected. If they did, then what would happen is: * foo would work correctly, because it was the first entry of user type. * bar would keep "lrwi" rights, because the previous entry (user=foo) was of the same type (both are "user" type), so Dovecot decided to add the rights on top of group=people entry rather than replace them. BTW. The other ACL bug/"feature" of automatically adding admin rights that was fixed in v1.2.15 was already fixed in v2.0.beta2.
participants (1)
-
Timo Sirainen