[Dovecot] Plan: ACL changes
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.
Am 26.11.2010 06:59, schrieb Timo Sirainen:
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.
Hi Timo, features are nice to have, but in real i dont think global acls are a widely used feature. So if it does not break something it might be welcome in principal
In real world scenario root can ever set user acl by script at mailbox creation time i.e postfixadmin has a create hook ,if needed, for sure this can be overrided by the user later ( which might not be liked by admins, anyway this can be corrected with a script i.e by cron too), but it should be enough for setting acls to i.e. postmaster for a pub namespace folder , which can be admined forcing administrate to users to subfolders later
for other stuff there is the master user feature, which should allow setting users acls whatever for admins like the real user is able too do
the only real problem i see, is like on fileservers, permissions/acls "get wild" over the time, and people lost overview what acls are users/ globals etc. ( but this is a problem ever )
after all whatever method you might implement it should work with dict mysql like users acls now do
-- Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
On 26.11.2010, at 6.42, Robert Schetterer wrote:
Hi Timo, features are nice to have, but in real i dont think global acls are a widely used feature. So if it does not break something it might be welcome in principal
Global ACLs already exist and are used by people, but they are just a bit annoying to use. The new feature would just be to add wildcard support for them.
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 26.11.2010, at 9.41, Thomas Leuxner 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.
+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?
Not really. Also I'm no longer sure how useful this #2 would be, or how exactly it should work.. The use cases I can think of can be solved with global ACLs supporting wildcards.
Am 26.11.2010 um 14:28 schrieb Timo Sirainen:
Not really. Also I'm no longer sure how useful this #2 would be, or how exactly it should work.. The use cases I can think of can be solved with global ACLs supporting wildcards.
Guess more input/thoughts would be beneficial. ACL inheritance should be possible in some way though...
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
On 28.11.2010, at 17.01, Charles Marcus wrote:
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?
ACL inheritance would require much more thinking about how exactly it should work. Otherwise it's just going to cause unexpected results.
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...
I have no idea about GPResult, but yeah, I've been thinking about some day adding "doveadm acl" command for manipulating ACLs and also giving a human-readable output of what ACLs exist for mailbox and asking what rights to what mailboxes different specific users would have.
Am 30.11.2010 01:03, schrieb Timo Sirainen:
On 28.11.2010, at 17.01, Charles Marcus wrote:
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?
ACL inheritance would require much more thinking about how exactly it should work. Otherwise it's just going to cause unexpected results.
a wided spreaded unexpected result might be users forget to set "list" acl on a top folder, so they cant see subfolder whatever acl permission is set there for them
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...
I have no idea about GPResult, but yeah, I've been thinking about some day adding "doveadm acl" command for manipulating ACLs and also giving a human-readable output of what ACLs exist for mailbox and asking what rights to what mailboxes different specific users would have.
-- Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
participants (4)
-
Charles Marcus
-
Robert Schetterer
-
Thomas Leuxner
-
Timo Sirainen