[
https://issues.apache.org/jira/browse/SLING-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17298440#comment-17298440
]
Eric Norman edited comment on SLING-9871 at 3/10/21, 12:21 AM:
---------------------------------------------------------------
Hi [~ashishc],
Did you have some expectation about what the syntax should look like to express
the order for the various ways of declaring ACLs?
I imagine that for the simple use case where the statement is setting an ACL on
a single resource for a single principal it may seem reasonable to declare an
order clause after the user/group name with something like this:
{code:java}
# set ACL for user on a resource
set ACL for bob order(first)
allow jcr:read on /content
end
# set acl on resource for principals
set ACL on /content
allow jcr:read for alice order(before bob)
allow jcr:read for fred order(after bob)
allow jcr:read for groupA order(last)
end{code}
But it looks like it would get a bit messy when the set ACL call gets more
complex and there is a matrix of principals + resources involved. In this
case, would the order clause apply the same rule for the whole matrix or
different choices per-user, per-resource, or both?
{code:java}
# set acl for multiple users on multiple resources
set principal ACL for alice,bob
allow jcr:read on /content,/var
end
# set acl on multiple resources for multiple users
set principal ACL on /content,/var
allow jcr:read for alice,bob
end
{code}
Or perhaps it would be simpler to create a new statement dedicated solely to
re-ordering the ACEs that already exist in an ACL and leave the "set ACL"
syntax alone? Maybe something like this that would be processed after all the
"set ACL" statements were processed:
{code:java}
# change order of ACEs on a resource for multiple users/groups
order ACL on /content
last for bob
first for groupA
before bob for alice
after groupA for fred
end {code}
was (Author: enorman):
Hi [~ashishc],
Did you have some expectation about what the syntax should look like to express
the order for the various ways of declaring ACLs?
I imagine that for the simple use case where the statement is setting an ACL on
a single resource for a single principal it may seem reasonable to declare an
order clause after the user/group name with something like this:
{code:java}
# set ACL for user on a resource
set ACL for bob order(first)
allow jcr:read on /content
end
# set acl on resource for principals
set ACL on /content
allow jcr:read for alice order(before bob)
allow jcr:read for fred order(after bob)
allow jcr:read for groupA order(last)
end{code}
But it looks like it would get a bit messy when the set ACL call gets more
complex and there is a matrix of principals + resources involved. In this
case, would the order clause apply the same rule for the whole matrix or
different choices per-user, per-resource, or both?
{code:java}
# set acl for multiple users on multiple resources
set principal ACL for alice,bob
allow jcr:read on /content,/var
end
# set acl on multiple resources for multiple users
set principal ACL on /content,/var
allow jcr:read for alice,bob
end
{code}
Or perhaps it would be simpler to create a new statement dedicated solely to
re-ordering the ACEs within an existing ACL and leave the "set ACL" syntax
alone? Maybe something like this:
{code:java}
# change order of ACEs on a resource for multiple users/groups
order ACL on /content
last for bob
first for groupA
before bob for alice
after groupA for fred
end {code}
> Specifying order of ACEs through repoinit directives
> ----------------------------------------------------
>
> Key: SLING-9871
> URL: https://issues.apache.org/jira/browse/SLING-9871
> Project: Sling
> Issue Type: Improvement
> Components: Repoinit
> Reporter: Ashish Chopra
> Priority: Major
>
> As of writing this, repoinit processor (among other things not relevant to
> this JIRA) collects {{create path}} statements and {{set ACL}} statements
> declared in all the feature-models applicable to feature-aggregate under
> consideration.
> Upon repository initialization, it applies all the {{create path}}
> statements, followed by all the {{set ACL}} statements. However, the order in
> which {{set ACL}} statements declared across feature models are applied isn't
> defined (currently, it seems to be based on feature-model-name,
> alphabetically ascending).
> This causes issues at times because we want the order of the ACEs to be
> maintained (e.g., "deny"s for everyone at a given path must be the first ACE,
> followed by "allow"s for specific, non-system-user principals)
> Repoinit should be able to support this requirement.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
