[
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.
