You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Robert Munteanu (JIRA)" <ji...@apache.org> on 2016/12/15 09:57:58 UTC

[jira] [Updated] (SLING-6398) Repoinit should not attempt to create access control entries when no changes are needed

     [ https://issues.apache.org/jira/browse/SLING-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Munteanu updated SLING-6398:
-----------------------------------
    Attachment: 0001-SLING-6368-Repoinit-should-not-attempt-to-create-acc.patch

[~bdelacretaz] - here's a patch that works for my scenario, with some tests added. 

I did not find a good way to test that the ACL is not set again, so I exposed an utility method from AclUtil and tested that.

The log entries are similar to

{noformat}15.12.2016 11:50:21.463 *INFO* [Apache Sling Repository Startup Thread] org.apache.sling.jcr.repoinit.impl.AclUtil Not adding [LocalAccessControlEntry# principal org.apache.jackrabbit.oak.security.user.SystemUserPrincipalImpl:sling-scripting, privileges: [jcr:read], isAllow : true] to path /libs since an equivalent access control entry already exists{noformat}

How does that look to you?

> Repoinit should not attempt to create access control entries when no changes are needed
> ---------------------------------------------------------------------------------------
>
>                 Key: SLING-6398
>                 URL: https://issues.apache.org/jira/browse/SLING-6398
>             Project: Sling
>          Issue Type: Improvement
>          Components: Repoinit
>            Reporter: Robert Munteanu
>            Assignee: Robert Munteanu
>             Fix For: Repoinit JCR 1.1.2
>
>         Attachments: 0001-SLING-6368-Repoinit-should-not-attempt-to-create-acc.patch
>
>
> I have a more complex Sling setup based on the recent Oak multiplexing additions.
> The repository is split bewteen
> - /libs and /apps, read-only
> - the rest of the repository, read-write
> When the provisioning model contains ACL definitions, they are processed directly without checking if they exist. In turn, Oak updates the definitions, even if equivalent ones exist. This causes the repoinit part to fail if it refers to ACLs for the read-only part of the repository.
> I would propose that the repoinit statements check if the ACL really needs to be replaced or if it can be skipped. This also has the advantage of making it symmetric with the checks for service users and paths and also should slightly reduce provisioning time.
> [~bdelacretaz] - would that work for you?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)