Issue #107 open

hierachical acls

Reimar Bauer
created an issue

For hierarchical acls it is important to know what a subitem of an item is. This is only based on the name currently. Is that correct? Because at setting up hacl it is done on items uuid mapping to the names in the hierarchy. If the item has more than one name, which are the valid rights? How does it work if an item has a name and a subitem name?

That looks rather complex now. May be we should replace hacl by something like range acls? By that we could setup in meta the ids of the items which have same rights as the item where we have acls defined.

Comments (7)

  1. Thomas Waldmann repo owner

    no, for hierarchical ACLs, it is important to know the PARENT name(s) of the item name in question. this is trivial, as the parent names are directly defined by the item name in question.

    in question: a/b/c parent: a/b grandparent: a

  2. Thomas Waldmann repo owner

    Name-based ACLs need more thinking!

    comment #1 was referring to the typical usecase when we fetch some specific item by url, so the item name is given.

    but there are other cases, e.g. search results, when we just have the revision meta or whoosh document, so we have a list of names, without any preference on one specific name.

    checking permissions (usually READ permissions) then means to check if any of the names allows it.

    for items/revisions with empty NAME list (==deleted stuff) it gets even a bit more complicated when considering name-based ACL mapping and (naturally name-based) hierarchical ACLs. if we have no name any more, what shall we do?

    potential permission changes also happen when adding/changing/removing names from the NAME list, so the problem is not limited to removing the last name from the NAME list, but is a very general problem with any name-based ACLs.

  3. Thomas Waldmann repo owner

    if an item has N names, hierarchical acl permission checks should check whether ANY of the N names gives permissions (do N hierarchical lookups). If no ACL is found that way, use default acl.

    if we do it that way, the behaviour for N == 0 (empty name list) is to use the default acl.

    for a rather permissive default acl, that would mean that restrictive ACLs on an item imposed by its name(s) due to hierarchical acls can get less restrictive if these names are removed (the item is deleted from those hierarchies). same thing happens btw if you ADD a name that is not part of a at-least-same-restrictive hierarchy. in general, weakening ACLs are problematic due to information disclosure.

    for a rather restrictive default acl (like not giving any rights by default), that would mean that relaxed ACLs on an item imposed by its name(s) due to hierarchical acls can get more restrictive if these names are removed. in general, ACLs getting more restrictive can mean an item gets out of control of a specific person. e.g. a person had access to X, changed/remove some name and by that loses access to it (can't change it back for example).

    so, we see that any permission change due to name changes has its problems. that means that hierarchically inherited acls are problematic, no matter how we do it (and this is not new, happened in moin 1.9 also).

  4. Thomas Waldmann repo owner

    one option we could implement when adding/changing/removing names (alias, rename, delete) is to determine the currently inherited ACLs and to COPY them to the revision metadata.

    that way, permissions would not change.

    when moving / aliasing whole subtrees, it should be enough to treat the root item of the subtree like this, because the hierarchy still exists in the same way at the new place.

    when removing names from whole subtrees (deleting), the hierarchy might go away (if there is no name left or if the names left do not form same hierarchy). depending on the case, we might need to copy ACLs to multiple or all new revisions.

    maybe an easy way to implement this is to compute ACLs before and after the change and copy previous-effective-acl to new revision if we detect a change.

  5. Yves Delley

    Why NAME-based hierarchical ACL's? Why not have a separate INHERIT_ACL meta pointing to the parent where ACL's should be inherited from? It could be automatically initialised upon creation based on the NAME.

  6. Thomas Waldmann repo owner

    Yves: sorry for late answer, I somehow have missed your comment.

    Currently, the hierarchy is defined by the name. But I understand your idea, which would be more flexible, but also somehow making the system more complex to understand.

    Notes:

    • due to a child having multiple parents (by name), we'ld also need INHERIT_ACL to be a list of ITEMIDs
    • idea would solve issues related to nameless items (or when just removing a name)
  7. Log in to comment