Applying access control lists using wiki hierarchy.

How does AccessControlList class work currently?

Acl objects are made from acl lines in config and page. First acl_before line is copied, then page lines are copied from page, or acl_default if page has not acl lines. Last, acl_after line is copied. Then, acl object is created from the lines. This object contain a list of right dictionaries. This object is created for each page and cached.

When accessing pages, user may mehtod is called, which retrive the acl object from the page and check for rights.

problems

• acl_before and acl_after are duplicated for every page

How should hierarchial acl work

The should work like file system permissions. Say there are the following pages, TopSecret and !TopSecret/!PasswordFiles . If the user "protects" TopSecret by removing read right to everyone but himself, it would naturally expect everything bellow TopSecret to be procected.

Benefits:

• Define only one acl line for whole tree of pages
• Can't give more rights to a part of a tree, you can only add protection
• Familiar and simple concept, less error prone
• Cheap to implement - if a user is not allowed by outer parts of the tree, there is not need to check inner parts.
• Need very small cache, keep in memory for faster access, faster to same/load from disk in cgi.

Problems:

• You can't add more right in the hierarchy, either move page to higher less protected area, or give use more rights in higher parts of the tree.

Implementations

Check parent then children

user.may is patched to to hierarchial check instead of single page check. Each page in the hierarchy is checked, if one of them does not give the user the requested right, it stops. If all page agree to give requested right, you have the right.

[http://aluminum.local/nirs@freeshell.org--2004/moin/moin--fix/moin--fix--1.3/patch-124/ patch-124]

Test: http://nirs.dyndns.org/fix/ParentPage

Problems

This will is not entirely the effect I suspect a inherited acl to work. Goal is that a user that has no rights in a wiki, but for one page, can create/edit/delete subpages of that page. Checking all pages in the path until none says no does not work, cause the non-existing last page will always say no... but its the right way, I think.

acl_rights_after is likely to block all access in a restricted wiki and so it will be impossible to add more rights on a lower tier or checking.

It does not make much sense to check acl_before and acl_after multiple times in a hierarchial check, but they are currently embedded in the page acl. The solution is to remove them from page acl, and use only page lines in page acl. acl_before and acl_after may be global acl objects we can query once before and after an hierarchial check.

acl_before can be renamed to wiki_acl, this make more sense when we talk about hierarchy.

I don't see why we need acl_after. Is there a configuration that can not be done without it?

• If a page has acl lines, acl_default does not come into play. So if there is no All: rule in the page acl, but you want one for all your pages, acl_after is needed. -- OliverGraf DateTime(2005-01-18T08:15:05Z)

This splits and precompiles before, after and default acls: attachment:split-before-after.diff Now the may routine has to get recursive over the page parents... -- OliverGraf DateTime(2005-01-18T08:58:32Z)

So, these are the fruits of my work: attachment:hierachical-acl.diff

It splits before, after and default as before and checks the parent if acl_inherit_parent is true. Still needs some tests. -- OliverGraf DateTime(2005-01-18T09:51:36Z)

Ahhh, stop. The diff has still a problem with edits and acls. Better version follows soon, I hope... -- OliverGraf DateTime(2005-01-18T09:59:03Z)

Inherit parent pages acl lines

Here when page acl is created, it copies all lines from parent pages, so the total lines page lines are acl_before + parents lines + page lines + acl_after

attachment:inherit-parent-acl.diff

Updated patch to moin--main--1.3--patch-556

But I think the solution above which splits the acls and and does not need all this cache-mangeling here would be the better way of doing it. -- OliverGraf DateTime(2005-01-18T08:15:05Z)

Problems

This will increase even more the acl cache, when parent lines are duplicated into all children in a tree. Kind of "flattening" acl hierarchy.