[ 
https://issues.apache.org/jira/browse/JCRVLT-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713776#comment-17713776
 ] 

Mark Adamcin commented on JCRVLT-683:
-------------------------------------

[~angela] The background for this ticket is documented in GRANITE-44323 and 
GRANITE-44324. The issue is not really about ac-setup per se, but about how the 
current implementation makes it difficult to reliably distribute mutable 
content (such as a keystore) located within a service user's authorizable node 
between repositories when they have different rep:principalPolicy nodes. 
Ideally, the package created by an Admin to distribute the mutable content for 
a service user would have a filter root with the absolute path to the 
authorizable node, and an acHandling option set to IGNORE. The current 
implementation quietly results in a surprising effect where, having installed 
the package, the service user loses the jcr:read permission on its authorizable 
node and the newly installed mutable content. The Admin can verify that the 
content is present in the UI, whereas the application logs indicate that the 
content is not present, when accessed by the service user's resource resolver.

> 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
>            Assignee: Konrad Windszus
>            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)

Reply via email to