[
https://issues.apache.org/jira/browse/SLING-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16140025#comment-16140025
]
Bertrand Delacretaz commented on SLING-7061:
--------------------------------------------
Your alternative syntax makes sense, and IIUC if we respect the order of
statements just inside the set/end blocks we're good w.r.t. your ordering
example?
If yes I think that's a strong reason for supporting that alternative syntax.
However there are also cases where it leads to having to duplicate principal
names, which is not convenient. So it's probably best to support both that
syntax and the "set ACL on repository for <1..N principals>" that I suggested?
I think that's not hard to do the way the parser is built. The principal names
cannot be in both places though, it's either "my" or "your" syntax but not a
mix of both.
As for ordering, you're right that composing various repoinit sources would
need to be checked as well, so if we can avoid that and only respect ordering
within statements that's much better IMO.
> 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)
