[
https://issues.apache.org/jira/browse/OAK-3627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15008527#comment-15008527
]
angela commented on OAK-3627:
-----------------------------
[~kwin], the Oak way of defining access control entries for non-existing nodes
is by the means of restrictions which reflect the following part of JSR 283
(section 16.3.5 Scope of a Policy):
{quote}
When an access control policy takes effect, it may affect the accessibility
characteristics not only of the node to which it is bound but also of nodes
elsewhere in the workspace.
[...]
One common case is a policy that affects both its bound node and the subgraph
below that node. However, any such deepness attribute is internal to the policy
and, like any other internal characteristic of a policy, opaque to the JCR API
except insofar as it is part of the human-readable name and description. Note
also that, strictly speaking, a policy is not required to affect even its bound
node, though such an implementation would be uncommon.
{quote}
as well as section 16.6.2 Permissions
{quote}
In repositories that do support access control management, the permissions
encompass the restrictions imposed by privileges, but also include any
additional policy-internal refinements with effects too fine-grained to be
exposed through privilege discovery. A common case may be to provide
finer-grained access restrictions to individual properties or child nodes of
the node to which the policy applies.
{quote}
for example: if you wish to grant a given principal access to the tree defined
by a non-existing node at _/a/b/c_, you could create an access control entry
for that principal at _/a_ and using {{rep:glob}} with a value {{/b/c}} to
limit the effect of this ACE to _/a/b/c_ (and not to _/a_ as it would be the
case without additionally narrowing down the effect).
as an additional node: the reason for the rather experimental secondary access
control model in Jackrabbit 2.x was the wish to have a access control
management which closer reflects the way how permissions are evaluated. it
turned out however that using this for access control management poses
considerable problems when it comes to properly securing it (see version
storage for a very similar issue). that's why we ended up merging the 2
approaches in the default Oak authorization implementation and making the
per-principal view what it actually was intended for: the system internal view
used for the evaluation which essentially is hidden from regular sessions (see
doc for exceptions).
so, what ever we come up with in the future to allow for creation of policies
for non-existing nodes which effectively means writing directly to the
permission store, requires careful evaluation and considerations of the attack
vectors and vulnerabilities that may be associated with it.
> Allow to set ACLs on not-yet existing nodes
> -------------------------------------------
>
> Key: OAK-3627
> URL: https://issues.apache.org/jira/browse/OAK-3627
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Konrad Windszus
>
> With Jackrabbit 2 it was possible to set ACLs for nodes which do not exist
> yet through Principal-based ACLs
> (http://wiki.apache.org/jackrabbit/AccessControl#Principal-based_ACLs).
> With Oak this is no longer possible as the principal based ACEs are not
> supported
> (https://jackrabbit.apache.org/oak/docs/security/accesscontrol/differences.html).
> Since there are valid use cases for setting ACEs prior to creating the
> according nodes it would be good, if Oak would support this as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
