Global ACLs are intended to apply to a few mailboxes for all users. For example
you could have a master user called "spam" that would have access to
each user's "spam" mailbox, but nothing else.
Global ACLs are kind of ugly. A mailbox's ACL is found from exactly the same
name as what the mailbox's virtual name is. So for example if you have
namespace {
separator = /
prefix = foo/
}
And you have a mailbox called foo/bar, the global ACL is looked up from the
<global dir>/foo/bar. The problem there of course is what if you want to
set global ACLs for "foo". You can't have both directory and a
file called "foo". So if this happens, Dovecot instead looks up the
ACLs from <global dir>/foo/.DEFAULT file. The name for this file is
slightly confusing, and also of course if there really is a mailbox called
".DEFAULT" it won't really work well.
Global acl is currently configured by giving its path to acl setting, such as:
plugin {
acl = vfile:/etc/dovecot/global-acls
}
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.
The * would match only within a single namespace, so if you had more than one,
the * entry would match only the one having prefix="". The * entry
would be especially helpful for master users who you intend to have access to
user's all mailboxes. Currently there is no good way to implement this.
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.
Any thoughts? Since neither of these would break backwards compatibility, I
could add them to v2.0.x.
On 26.11.2010, at 5.49, Timo Sirainen wrote:> 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.Oh, a thought: A default ACL is about what ACLs are applied to a mailbox that doesn't yet have any ACL (or copying ACLs to a newly created mailbox on namespace root level). But would it be also useful to have ACLs that are always added on top of existing ACLs for a mailbox, even if it already has some ACLs set for it? Global ACLs already do this, but would it be useful to have also per-namespace "global" ACLs that acted that way? Possibly not.. But how useful would default ACLs be either? Maybe global ACLs with support for wildcards are all that is needed.
On Fri, Nov 26, 2010 at 05:49:16AM +0000, 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.+1 Would this also allow -w by looking at the example. Should cater for most cases then.> 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. >+1 I remember the discussions where set around recursion for this feature: e.g. applying to newly created folders/mailboxes. Is this also planned by #2? Regards Thomas
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