[Dovecot] ACL handling bugs in v1.2.8+ and v2.0

[Timo Sirainen]

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 at 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.