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

Karl Pauls closed SLING-9970.
-----------------------------

> SystemUser.getPath doesn't reflect the repository path
> ------------------------------------------------------
>
>                 Key: SLING-9970
>                 URL: https://issues.apache.org/jira/browse/SLING-9970
>             Project: Sling
>          Issue Type: Bug
>          Components: Content-Package to Feature Model Converter
>            Reporter: Angela Schreiber
>            Assignee: Karl Pauls
>            Priority: Major
>             Fix For: Content-Package to Feature Model Converter 1.1.0
>
>
> I tried to find out why {{AccessControlEntry}} is constructed with 2 
> different {{RepoPath}}s one reflecting the path as obtained from the parser 
> and one containing the path converted to 'repository path' using 
> {{PlatformNameFormat.getRepositoryPath(resourcePath)}}.
> from what i see the 'repository' path contained in the entry is later used to 
> create the hierarchy down to access controlled nodes that hold the 
> resource-based access control policy with the entries.
> but looking at the usages of the 'path' field i found that it is only used in 
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/accesscontrol/DefaultAclManager.java#L152
>  (see also SLING-9953)
> {code}
>  // clean the unneeded ACLs, see SLING-8561
>         if (authorizations != null) {
>             Iterator<AccessControlEntry> authorizationsIterator = 
> authorizations.iterator();
>             while (authorizationsIterator.hasNext()) {
>                 AccessControlEntry acl = authorizationsIterator.next();
>                 if (acl.getPath().startsWith(systemUser.getPath())) {
>                     authorizationsIterator.remove();
>                 }
>             }
>         }
> {code}
> this finding lead me to the conclusion that the {{SystemUser}} object is in 
> fact created with a path that doesn't actually represent the JCR path as 
> found in the repository.
> so, all usages of {{SystemUser.getPath}} used to create the system user will 
> potentially use the 'wrong' path. for example:
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/accesscontrol/DefaultAclManager.java#L105
> {code}
>      // TODO does it harm?!?
>      addSystemUserPath(formatter, systemUser.getPath());
> {code}
> which the issues the following repo-init statement
> {code}
> formatter.format("create path (rep:AuthorizableFolder) %s%n", path);
> {code}
> and
> https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/accesscontrol/DefaultAclManager.java#L109
> {code}
> formatter.format("create service user %s with path %s%n", systemUser.getId(), 
> systemUser.getPath());
> {code}
> upon a quick (but maybe incomplete) search I didn't find any usage of 
> {{SystemUser.getPath()}} that would require it to reflect the path as 
> extracted from the content package.... if that was true, the method should be 
> renamed to 'getRepositoryPath' and should return the converted  path (see 
> above).
> Having this addressed would IMO subsequently allow to drop the duplicated 
> path argument from the {{AccessControlEntry}} and drop the {{getPath}} method 
> altogether. which anyway seems a bit confusing to have. let me know if i 
> should create a separate issue for this follow up clean up.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to