[
https://issues.apache.org/jira/browse/SLING-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17301813#comment-17301813
]
Ashish Chopra commented on SLING-9871:
--------------------------------------
hi [~enorman], [~bdelacretaz], I am sorry I couldn't respond to your calls for
feedback in-time.
I agree that documenting the order in which ACLs are created by repoinit
directives would definitely be a start, but I don't think that can be a
conclusion for this issue.
I raised this because our product uses Sling repoinit as a substitute of
[Jackrabbit Filevault packages|https://jackrabbit.apache.org/filevault/] for
creating ACLs in customer-owned paths of JCR repository (e.g., {{/content}}).
Since it is not a good practice (or even possible, at times) to create the
paths where ACEs are to be applied, we often use restrictions on parent
"root"-paths (e.g., over /content, or /content/dam) for different users/groups.
Developers often end up adding ACLs for users/groups in their own
feature-models. This is where the ability to determine (and specify order)
becomes extremely very important ({{set ACL}} statements present in different
feature models, if applied in a non-deterministic and non-specifiable manner,
can cause final access-control setup to differ significantly from what's
desired to create a secure deployment).
Not being able to order the ACLs once created, even when JCR APIs and
consequently
[Sling|https://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html#acls-and-principals-1]
and Filevault allow it
([through|http://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling#MERGE_PRESERVE]
[merge|http://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/io/AccessControlHandling#MERGE]
modes), will create a parity gap for our internal developers as well as our
customers. I worry that with sole reliance on repoinit directives to manage
Access Control, it may not be possible for us to correct severe security issues
should a flaw be discovered in the ACL setup at a given point in time.
bq. 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
I personally find this approach amenable - this would be similar to how all
{{create path}} directives are applied before all {{set ACL}} directives (i.e.,
all {{order ACL}} directives can be applied after {{set ACL}} directives have
been processed). The order in which {{order ACLs}} directives are aggregated
across features can be same as that for {{set ACL}} directives (which I think
we all agree should be deterministic and documented).
That said, I think the vocabulary would need to evolve to target more specific
ACEs - e.g., we might need to (at least) need to account for deny and allow
ACEs while specifying an order.
[~angela], would you also have an opinion on this ticket in general, and the
[3rd proposal
here|https://issues.apache.org/jira/browse/SLING-9871?focusedCommentId=17298440&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17298440]
in particular?
> 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)
