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

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

I'm working on those ITs. I think it is really only an issue with 
rep:PrincipalPolicy nodes in practice, because of that reason that you mention. 
Traditional ACLs are rarely added as children of non-system user accounts, 
because non-system user accounts are not generally not located at predictable 
(or even human-readable) paths, and so permissions over their home nodes is 
usually granted at the level of /home or /home/users via group membership. 
Permissions on resources outside of /home for normal users are also granted by 
traditional ACLs on those resources, so the replacement of an existing normal 
user's Authorizable node on import ultimately does not affect any of that 
user's applicable policies. Someone might come along with a use case for 
preserving traditional ACLs under rep:User or rep:SystemUser nodes, but that I 
think any such case could be solved by authorizable folder management.

> 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
>
> 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