[
https://issues.apache.org/jira/browse/JCRVLT-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCRVLT-292:
--------------------------
Attachment: JCRVLT-292.patch
Status: Patch Available (was: Open)
[~tripod], attached an IT illustrating the issue and a proposed patch of
{{JackrabbitACLImporter}}. The test fails without the patch but passes with the
fix in place... however see JCRVLT-293 for other test failure, which I am not
entirely sure how to weight them.
While I think the proposed fix actually introduces a backwards compatibility
issue, the fix doesn't seem to cause other tests to fail. I would feel a lot
more comfortable with the proposed fix, if there was a bigger test coverage
(both IT and unit tests) that would help me understand if the behaviour today
was actually intended or if we are really looking at a bug (or improvement)
here.
> Order of ACLs are altered on installation of content packages
> -------------------------------------------------------------
>
> Key: JCRVLT-292
> URL: https://issues.apache.org/jira/browse/JCRVLT-292
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
> Reporter: angela
> Priority: Major
> Attachments: JCRVLT-292.patch
>
>
> When installing a content package with AccessControlHandling _overwrite_
> access control entries contained in a given list are grouped by principal and
> ultimately imported with a different order that originally defined in the
> package.
> This alters the effective permissions for those {{Subject}}s that contain the
> principals for which the ACEs got imported.
> Example:
> 1. grant group1 read at /testroot
> 2. deny group2 read at specific subset of items within the tree defined by
> /testroot
> 3. grant group1 read/write at specific subset of items within the tree
> defined by /testroot
> The ACL resulting from the package import will contain the entries in the
> following order: 1, 3, 2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
