[
https://issues.apache.org/jira/browse/SLING-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306293#comment-17306293
]
Ashish Chopra commented on SLING-9871:
--------------------------------------
hi [~bdelacretaz],
bq. could you supply a minimal example, using aggregated features, where the
end result is not what you expect, or not fully deterministic?
I'd like to mention at the outset that the results are fully deterministic per
my experiments (even if not documented publically), and it isn't not about what
one _expects_, but rather about what's _desired_ and can't be achieved without
creating a single feature model with all the {{set ACL}} statements.
Building over the example I listed at [0], consider:
* feature-model-1:
{noformat}
create group assets-users
add assets-users to group everyone
set ACL for assets-users
allow jcr:read on /conf with restrictions(*/settings/*/assets)
end
{noformat}
* feature-model-2
{noformat}
create group sites-users
add sites-users to group everyone
set ACL for sites-users
allow jcr:read on /conf with restrictions(*/settings/*/sites)
end
{noformat}
* feature-model-3
{noformat}
set ACL on /conf
deny jcr:read for everyone
end
{noformat}
results in following access-control structure in the repository when the three
models above are aggregated:
{noformat}
/conf
- rep:policy
- assets-users : allow : jcr:read rep:glob="*/settings/*/assets"
- sites-users : allow : jcr:read rep:glob="*/settings/*/sites"
- everyone : deny : jcr:read
{noformat}
Since {{assets-users}} and {{sites-users}} are members of {{everyone}} group,
any members of {{assets-users}} and {{sites-users}} won't be able to access the
restricted paths, rendering the first two ACEs ineffective.
----
The order that's _desired_ is:
{noformat}
/conf
- rep:policy
- everyone : deny : jcr:read
- assets-users : allow : jcr:read rep:glob="*/settings/*/assets"
- sites-users : allow : jcr:read rep:glob="*/settings/*/sites"
{noformat}
and one way to make happen right now definitively is to ensure that the
_complete_ access-control setup is present in a single feature-file and define
the ACEs in the order they are desired. And all the developers update the ACEs
in this single feature-file only eithout exception.
This is what creates ownership issues mentioned at [0] and negates some of the
advantages of having different feature-files in the first place.
The other (less obvious and more fragile) way is to rename "feature-model-3" to
something like "a-feature-model-3", or basically any name that causes it to be
ranked lexicographically higher than the other two feature-models.
Does that help somewhat?
[0]
https://issues.apache.org/jira/browse/SLING-9871?focusedCommentId=17304635&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17304635
> 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)
