[Dovecot] Plan: ACL changes

[Charles Marcus]

On 11/26/2010 12:49 AM, Timo Sirainen wrote:
> So plan #1: deprecate this usage. If global-acls is a directory, keep
> using the old method. But the new preferred method would be for it to
> be a file that contains all of the global ACLs. Typically there
> should be very few entries, so this should also be more efficient.
> Also this would allow setting default ACLs for namespaces by using
> wildcards. For example you could have:
> 
> * masteruser +lrw
> spam spamuser +lr
> test/* testuser +lr
> etc.

Huge +1

> Plan #2: Add support for per-user default namespace ACLs. In the
> mail root directory if "dovecot-default-acl" file exists, it's used
> as the default ACLs. I'm not entirely sure what should happen if it 
> conflicts with the global ACLs. Probably they both should be simply 
> merged, since both can only be created by an admin. Probably the 
> per-user ACL should be allowed to override the global ACLs.

It 'kind of' sounds like you're referring ("Probably they should be
merged...") to something that has been discussed previously, namely, ACL
'inheritance'. Any chance that true ACL inheritance (change the parent,
ACLs propogate to all sub-folders that have the 'inherit' flag set)
could be added to this list? Or would that constitute more invasive changes?

> Any thoughts? Since neither of these would break backwards 
> compatibility, I could add them to v2.0.x.

Again +1 :)

For large/complex environments, it would also be *really* nice if there
was a tool available to get a resulting tree 'view' of the ACLs and
where each got set, to make sure that what you set is what you wanted -
something like Microsoft's GPResult tool for checking the results of
Group Policies in a Windows Domain environment. The tool could give a
broad overview of an entire mail system, or on a more granular level,
who has access to any given users folders, or, show all access rights to
all folders that any given user has access to, etc... maybe even check
ACLs against file-system permissions to make sure there are no conflicts
there... anyway, just thinking out loud...

-- 

Best regards,

Charles