Resent because of line wrapping issues. > Users always get the highest permission assigned to the same > namespace. So if you give read access to @ALL on the root namespace, > then you can do restrictions only for sub namespaces. Eg. this would > restrict access for guest users on the secret namespace. All other > users would still have read access (or upload if they belong to the > @users group). > > * @ALL 1 > * @users 8 > secret:* @guests 0 > secret:* @users 8 > I'm aware of that and was wondering if it would be possible to change it so that "none" always wins if present and that inheritance was optional. In that case you could easily shut a certain group out of the entire wiki. Here's an example of how it would work, a wiki that's basically open for reading, but with some closed sections: * @ALL 1 * @no_access 0 playground:* @ALL 16 secret:* @trusted_readers 1 #INHERIT:OFF secret:management:* @trusted_management 16 public:project_one:* @project_one_users 16 public:project_one:work_in_progress billy 2 #UNDERCONSTRUCTION;INHERIT:OFF public:project_two:* @project_two_users 16 - @ALL has read permissions in the root and all namespaces below, unless inheritance is turned off and/or explicit permissions for @ALL is given. - @no_access has no permissions in the root and all namespaces below, unless inheritance is off and explicit permissions for @no_access is given. - The namespace "playground" inherits permissions from the root namespace, @ALL is also given higher permissions, resulting in "delete" permissions for @ALL (because higher permissions take precedence, unless "none" is active) to "playground" and anything below. - The "secret" namespace has inheritance turned off and thus @trusted_readers are the only ones that have access. - The "secret:management" namespace inherits permissions from "secret" and adds higher permissions for the group @trusted_management. You have to be a member of either @trusted_readers (inherited) or @trusted_managers to read anything below "secret:management", and only @trusted_management can edit. If you are a member of @trusted_management but not @trusted_readers, you can't read directly below "secret", but you can access "secret:management" and below. - The "public:project_one" namespace inherits permissions from the root and adds higher permissions for @project_one_users. - The permissions for page "public:project_one:work_in_progress" has been added by the plugin UNDERCONSTRUCTION. It has inheritance turned off and only the user billy has access to it, rendering it "invisible" to other users. The ACL behaviour would look something like this: - "None" always prevails if present. - Permission inheritance is default active, but can be turned off per namespace/page. Perhaps globally. - ACL:s are checked from the page all the way back to the root namespace, unless "none" is present somewhere (inheritance has to be considered). - In case of a user/groups having several permissions, the highest is activated, unless "none" is present. If I have understood the way ACL's are currently working in DokuWiki, this is what the above settings would look like currently: * @ALL 1 * @no_access 0 playground:* @ALL 16 playground:* @no_access 0 secret:* @trusted_readers 1 secret:* @ALL 0 secret:management:* @trusted_management 16 public:* @no_access 0 public:project_one:* @project_one_users 16 public:project_one:work_in_progress billy 2 #UNDERCONSTRUCTION public:project_one:work_in_progress @ALL 0 #UNDERCONSTRUCTION public:project_two:* @project_two_users 16 However, since higher permissions always prevail, members of @no_access will have the same permissions as @ALL (as it contains all users). For example, @no_access can read everything below the public namespace, except billy's work_in_progress. As you can see, there are several more ACL entries here than in the previous example, but the result is still less secure. Extrapolate this ACL list to an environment with thousands of users and dozens of namespaces in the root and you probably see why I want this to change, if possible. The difference is that with "higher always wins", you can't use @ALL to set the basic permissions, since @ALL literally means everyone. You would have to split all users in two (or more) groups with exclusive memberships, "access_denied" and "all_except_those_in_access_denied", which is a impractical when you have a couple of thousand users. If "none" always wins, you use @ALL to set basic permissions and create specific groups for those that should not have access, but all users can always be members of @ALL. If you add the option to turn off inheritance, you get a more powerful ACL system that should simplify things even more. ACL's - in any way, shape or form - are always messy and complex, hopefully I haven't completely missed something. /Daniel -- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist