[
https://issues.apache.org/jira/browse/SLING-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16140017#comment-16140017
]
Timothee Maret commented on SLING-7061:
---------------------------------------
bq. can you provide an example?
Assuming this setup defined in a provisioning model
{code}
# user1 is member of group1
set repository ACL for user1
allow perm1
end
set repository ACL for group1
deny perm1
end
{code}
If the order of execution is defined, for instance from top to bottom in the
provisioning model, then the repository setup will deterministic.
If the order of execution is not defined, then we don't know if user1 will be
denied or allowed permission for perm1.
bq. Or an alternate syntax that works better for your case.
The alternative syntax may have been
{code}
set ACL on repository
allow perm1 for user1
deny perm1 for group1
end
{code}
bq. I think so but if we need that it must be demonstrated by automated tests.
Ok, I'll give it a try.
In general, I think the order also needs to be defined when composing
provisioning models.
> Access control setup of repository-level permissions (i.e. null path)
> ---------------------------------------------------------------------
>
> Key: SLING-7061
> URL: https://issues.apache.org/jira/browse/SLING-7061
> Project: Sling
> Issue Type: Improvement
> Components: Repoinit
> Affects Versions: Repoinit Parser 1.1.0
> Reporter: angela
> Assignee: Timothee Maret
> Fix For: Repoinit Parser 1.1.2, Repoinit JCR 1.1.6
>
>
> If I am not mistaken it is currently not possible to create access control
> setup for principals at the 'null' path, which according to JSR 283 is to be
> used to setup repository level permissions such as
> - node type definition management (i.e. registering new node types)
> - namespace management (i.e. registering new namespaces)
> - privilege management (i.e. registering new privileges)
> - workspace management (i.e. creating/removing workspaces)
> All of these operations are not bound to a path (like e.g. removing an item
> or creating a new version for a given node) but instead take global effect on
> the whole JCR repository... that's why permissions for these operations
> cannot be granted at a given path.
> In the default authorization model shipped with Jackrabbit and Oak the -null-
> path access control policy is stored with a dedicated _rep:repoPolicy_ node
> located with the root node and
> For service user definitions we need to be able to define entries for the
> -null- path policy for the reasons explained above. Thanks for extending the
> repo-init accordingly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
