sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothee Maret (JIRA)" <>
Subject [jira] [Commented] (SLING-7061) Access control setup of repository-level permissions (i.e. null path)
Date Thu, 24 Aug 2017 13:16:00 GMT


Timothee Maret commented on SLING-7061:

bq. can you provide an example?

Assuming this setup defined in a provisioning model

# user1 is member of group1

set repository ACL for user1
    allow perm1

set repository ACL for group1
    deny perm1

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

set ACL on repository
    allow perm1 for user1
    deny perm1 for group1

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:
>             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
> 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

View raw message