[
https://issues.apache.org/jira/browse/JCRVLT-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17712695#comment-17712695
]
Konrad Windszus edited comment on JCRVLT-683 at 4/15/23 6:02 PM:
-----------------------------------------------------------------
I was looking into this and basically this requires the following changes:
- Before deleting a node during import (in DocViewImporter#endDocViewNode(...)):
-- check if it contains a principal ACL (resource ACLs don't matter, as they
are no longer relevant if the according resource is removed, while for
authorizables they might still be relevant, as authorizables might be recreated
through the package at another location)
-- store the principal ACL in some temporary object
- When creating a new authorizable
-- Persist its authorizable id in some helper object
- At the end of the import:
-- Restore those principal ACLs according to the ACImportMode which refer to
authorizables which have been (re)created by the package
This does potentially have a major performance impact, because there is no
official API for both JR2/Oak which allows to figure out below which path a
User/Group may exist at all (to bail out quickly and not trigger a
search/traversal for ACLs below nodes which may never contain authorizables).
In Oak the user/group entry path is maintained in
https://github.com/apache/jackrabbit-oak/blob/c6ddcc55bee3de915459af01e91edad32d538f3d/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/UserProvider.java#L176-L177
and the UserProvider is a private field in
https://github.com/apache/jackrabbit-oak/blob/c6ddcc55bee3de915459af01e91edad32d538f3d/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/UserManagerImpl.java#L79.
Just going with the defaults won't work either, as AEM overwrites the default
user/group root path from
https://github.com/apache/jackrabbit-oak/blob/c6ddcc55bee3de915459af01e91edad32d538f3d/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/user/UserConstants.java#L119.
was (Author: kwin):
I was looking into this and basically this requires the following changes:
- Before deleting a node during import (in DocViewImporter#endDocViewNode(...)):
-- check if it contains a principal ACL (resource ACLs don't matter, as they
are no longer relevant if the according resource is removed, while for
authorizables they might still be relevant, as authorizables might be recreated
through the package at another location)
-- store the principal ACL in some temporary object
- When creating a new authorizable
-- Persist its authorizable id in some helper object
- At the end of the import:
-- Restore those principal ACLs according to the ACImportMode which refer to
authorizables which have been (re)created by the package
This does potentially have a major performance impact, because there is no
official API for both JR2/Oak which allows to figure out below which path a
User/Group can be maintained at all (to bail out quickly), as each potential
hit needs to be traversed fully for ACLs to store.
In Oak the user/group entry path is maintained in
https://github.com/apache/jackrabbit-oak/blob/c6ddcc55bee3de915459af01e91edad32d538f3d/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/UserProvider.java#L176-L177
and the UserProvider is a private field in
https://github.com/apache/jackrabbit-oak/blob/c6ddcc55bee3de915459af01e91edad32d538f3d/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/UserManagerImpl.java#L79.
Just going with the defaults won't work either, as AEM overwrites the default
user/group root path from
https://github.com/apache/jackrabbit-oak/blob/c6ddcc55bee3de915459af01e91edad32d538f3d/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/user/UserConstants.java#L119.
> Import of Authorizable node with acHandling=IGNORE should preserve existing
> rep:principalPolicy child node
> ----------------------------------------------------------------------------------------------------------
>
> Key: JCRVLT-683
> URL: https://issues.apache.org/jira/browse/JCRVLT-683
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
> Affects Versions: 3.6.6
> Reporter: Mark Adamcin
> Priority: Major
> Fix For: 3.6.10
>
>
> For situations where an authorizable node may be distributed from another
> environment where a different rep:principalPolicy for the user is defined
> than exists for that user in the target environment, it is important that the
> existing rep:principalPolicy be preserved when acHandling is unset,
> acHandling=IGNORE, or acHandling=MERGE_PRESERVE.
> Currently, the effective behavior of such a package install, as [it appears
> to be implemented in
> DocViewImporter|https://github.com/apache/jackrabbit-filevault/blob/5f9657374bd6c2d3dd1f6e9e2be0b9f5b25ddc26/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewImporter.java#L782-L787],
> results in the following:
> * If the package specifies acHandling=IGNORE, the existing
> rep:principalPolicy is deleted without replacement, regardless of whether the
> package contains its own rep:principalPolicy, which is equivalent to
> *acHandling=CLEAR*
> * If the package specifies acHandling=MERGE_PRESERVE or MERGE, the existing
> rep:principalPolicy is replaced with whatever rep:principalPolicy is
> contained in the package, or deletes the policy if a replacement is not
> present, which is equivalent to *acHandling=OVERWRITE*
> Unexpectedly, the least destructive (and most default) acHandling mode
> (IGNORE) turns out to be as destructive to packaged system user permissions
> as choosing any other mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
