[
https://issues.apache.org/jira/browse/SLING-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304635#comment-17304635
]
Ashish Chopra edited comment on SLING-9871 at 3/19/21, 4:27 AM:
----------------------------------------------------------------
hi [~enorman],
bq. Do your requirements need more complexity, where a principal may have more
than one ACE with (for example) different restrictions or something that need
to be in some specific order?
The cases I was dealing with had exactly this issue. For a given principal
there were two ACEs with different "types" (one was deny, other was allow) _as_
well are different restrictions. Since the last ACE wins, I had to ensure that
the the "allow with restrictions" id added _after_ the (wider) "deny".
The "allow with restrictions" ACE was added by a repoinit directive in a
feature-model file that was being processed _before_ the one containing the
"deny" ACE, messing up the order.
The only way I could address that was by:
* "guessing" that the feature-model file processing order is alphabetical, and
that's what repoinit {{set ACL}} implicitly uses to decide in which order to
add ACEs
* creating a _third_ feature-model file which contained the "deny" ACE
attempted to reorder.
Not only is it hard to figure out for the uninitiated, it results in
proliferation of feature-models at best and loss of ownership of the
development teams for their ACEs for shared principals at worst.
bq. I'm not sure how we would be able to uniquely identify which ACE is which
in that scenario for the purpose of ordering them. For that use case it seems
to me that there would need to be some way to store an "id" with each ACE that
you could reference?
I'm not aware if Oak has such a (hidden or otherwise) {{id}} or such for a
rep:policy node - however I think the identifier can purely exist at
repo-initializer level.
{{allow}}/{{deny}} directives in a {{set ACL}} block already support a {{with
restrictions(...)}}. If it can be further enhanced to add an optional {{with
id(<any_string>)}} or such, it should be possible to write targetted ordering
instructions.
e.g. in {{feature-model-1}}
{noformat}
set ACL for bob
allow jcr:read on /conf with restrictions(*/settings/*/assets) and
id(bob_reads_assets_settings)
end
{noformat}
in {{feature-model-2}}
{noformat}
set ACL for alice
allow jcr:read on /conf with restrictions(*/settings/*/sites) and
id(alice_reads_sites_settings)
end
{noformat}
and, in {{feature-model-3}}
{noformat}
set ACL on /conf
deny jcr:read for everyone with id(no_one_reads_conf_root)
end
{noformat}
In the example above, bob and alice are members of the group "everyone", and we
want bob's and alice's read ACEs to be added after everyone's deny for them to
be able to read respective settings that they have access to.
Given the order in which the feature-files are aggregated and processed today,
this isn't possible. At the moment, the only way to achieve the desired order
is to move all three setups to a common feature-model and order them as
desired, but suffers from the concerns noted above (thus negating the benefits
of fully contained feature-model definitions).
However, if {{feature-model-1}} can add something like:
{noformat}
order ACL
bob_reads_assets_settings after no_one_reads_conf_root
end
{noformat}
and {{feature-model-2}} has
{noformat}
order ACL
alice_reads_sites_settings after no_one_reads_conf_root
end
{noformat}
or alternatively,
{{feature-model-3}} has
{noformat}
order ACL
first no_one_reads_conf_root
end
{noformat}
the final ordering would be as desired, all the while leaving the onwership of
the ACEs in the respective feature-models.
My proposal above:
* doesn't address the scenarios where {{set ACL}} targets multiple
principals/resources
** I think the ability to target multiple entities is a matter of convenience,
and it should be OK to ask the developer to give this convenience up if
ordering is desired.
* assumes that {{id}} can't collide
** repoinit parser can be enhanced to throw invalid-syntax errors if ids
specified under {{set ACL}} directives collide.
was (Author: ashishc):
hi [~enorman],
bq. Do your requirements need more complexity, where a principal may have more
than one ACE with (for example) different restrictions or something that need
to be in some specific order?
The cases I was dealing with had exactly this issue. For a given principal
there were two ACEs with different "types" (one was deny, other was allow) _as_
well are different restrictions. Since the last ACE wins, I had to ensure that
the the "allow with restrictions" id added _after_ the (wider) "deny".
The "allow with restrictions" ACE was added by a repoinit directive in a
feature-model file that was being processed _before_ the one containing the
"deny" ACE, messing up the order.
The only way I could address that was by:
* "guessing" that the feature-model file processing order is alphabetical, and
that's what repoinit {{set ACL}} implicitly uses to decide in which order to
add ACEs
* creating a _third_ feature-model file which contained the "deny" ACE
attempted to reorder.
Not only is it hard to figure out for the uninitiated, it results in
proliferation of feature-models at best and loss of ownership of the
development teams for their ACEs for shared principals at worst.
bq. I'm not sure how we would be able to uniquely identify which ACE is which
in that scenario for the purpose of ordering them. For that use case it seems
to me that there would need to be some way to store an "id" with each ACE that
you could reference?
I'm not aware if Oak has such a (hidden or otherwise) {{id}} or such for a
rep:policy node - however I think the identifier can purely exist at
repo-initializer level.
{{allow}}/{{deny}} directives in a {{set ACL}} block already support a {{with
restrictions(...)}}. If it can be further enhanced to add an optional {{with
id(<any_string>)}} or such, it should be possible to write targetted ordering
instructions.
e.g. in {{feature-model-1}}
{noformat}
set ACL for bob
allow jcr:read on /conf with restrictions(*/settings/*/assets) and
id(bob_reads_assets_settings)
end
{noformat}
in {{feature-model-2}}
{noformat}
set ACL for alice
allow jcr:read on /conf with restrictions(*/settings/*/sites) and
id(alice_reads_sites_settings)
end
{noformat}
and, in {{feature-model-3}}
{noformat}
set ACL on /conf
deny jcr:read for everyone with id(no_one_reads_conf_root)
end
{noformat}
In the example above, bob and alice are members of the group "everyone", and we
want bob's and alice's read ACEs to be added after everyone's deny for them to
be able to read respective settings that they have access to.
Given the order in which the feature-files are aggregated and processed today,
this isn't possible.
However, if {{feature-model-1}} can add something like:
{noformat}
order ACL
bob_reads_assets_settings after no_one_reads_conf_root
end
{noformat}
and {{feature-model-2}} has
{noformat}
order ACL
alice_reads_sites_settings after no_one_reads_conf_root
end
{noformat}
or alternatively,
{{feature-model-3}} has
{noformat}
order ACL
first no_one_reads_conf_root
end
{noformat}
the final ordering would be as desired, all the while leaving the onwership of
the ACEs in the respective feature-models.
To account for any ACEs that the current feature aggregate doesn't define, the
(re-)ordering can be done after all the ACEs have been added. The impl can
'match' existing ACEs with the ids specified in the directives before
attempting to reorder them. Since ids are optional, the (re-)ordering must be
limited to only those ACEs that define one.
At the moment, the only way to achieve the desired order is to move all three
setups to a common feature-model and order them as desired, but suffers from
the concerns noted above (thus negating the benefits of fully contained
feature-model definitions).
My proposal above:
* doesn't address the scenarios where {{set ACL}} targets multiple
principals/resources
** I think the ability to target multiple entities is a matter of convenience,
and it should be OK to ask the developer to give this convenience up if
ordering is desired.
* assumes that {{id}} can't collide
** repoinit parser can be enhanced to throw invalid-syntax errors if ids
specified under {{set ACL}} directives collide.
> 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)
