jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weston Bustraan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2488) Add the ability to disable inheriting ancestor ACLs
Date Tue, 09 Feb 2010 14:33:27 GMT

    [ https://issues.apache.org/jira/browse/JCR-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831471#action_12831471
] 

Weston Bustraan commented on JCR-2488:
--------------------------------------

Here's my use case for this behavior:

I have a structure that looks something like this:

/SomeFolder/AnotherFolder/DocTemplate/PrivateItem

Users need to have jcr:read access to navigate down to the DocTemplate node. Using the template,
they then create instance nodes underneath it. However, these nodes (PrivateItem) can potentially
contain confidential information, such as sensitive medical information governed by HIPAA
laws, so the nodes need to be able to be locked down to only the person who created it and
any people they've granted permission to.

In the current ACL system, PrivateItem will inherit the jcr:read permissions of all the nodes
above it, making it virtually impossible to secure the item. Potentially, I *could* add individual
DENY ACEs to the PrivateItem that negate all the permissions inherited from the ancestors,
but if someone added a new ACE to an ancestor after the fact, then suddenly an unauthorized
person could have access. (Other suggestions of how to solve this issue using the current
system are welcome.)

My suggestion would be to add a flag like "rep:noInherit" (or something) to rep:ACL that would
prevent inheritance only when the property is present. This would allow the default behavior
and only prevent inheritance when explicitly set. Doing it like this would not require existing
installations to change or do anything different.

There is a concept almost identical to this in the Windows NTFS filesystem. I'll attach a
screenshot of the flag I'm referring to.

However, if you decide that this isn't something that would be beneficial to the Jackrabbit
user base as a whole, I'm OK with the ability to subclass the ACE collector and alter the
behavior. As it stands now, that's how I'm accomplishing this; but it's an ugly hack requiring
me to locate my subclass in the {{org.apache.jackrabbit.core.security.authorization.acl}}
package in order to make use of the {{ACLTemplate}} class.

Do you know how soon custom collectors functionality might be available?



> Add the ability to disable inheriting ancestor ACLs
> ---------------------------------------------------
>
>                 Key: JCR-2488
>                 URL: https://issues.apache.org/jira/browse/JCR-2488
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: security
>    Affects Versions: 2.0.0
>            Reporter: Weston Bustraan
>            Assignee: angela
>            Priority: Minor
>         Attachments: windows-xp-permission-inheritance.jpg
>
>
> The current ACL implementation will walk the tree from the item being accessed, up to
the root, collecting ACL entries for all the ancestors. With this system, there is no easy
way to restrict access to subnodes except by adding DENY entries to negate the entries inherited
from the parent nodes.
> I'd like to request a way to turn this behavior off either at a node level or global
level.
> The place where recursion is happening is in org.apache.jackrabbit.core.security.authorization.acl.ACLProvider$Entries.collectEntries(NodeImpl
node). Inside this method, it could perhaps check a global parameter or the existence of property
of the ACL policy node to determine whether to recurse up the tree.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message