[
https://issues.apache.org/jira/browse/JCR-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCR-2630.
-------------------------
Resolution: Fixed
fixed at revision 945528 including for #canReadAll() and #grants(Path, int)
where the same inconsistency appeared and added
test cases for the former inconsistency.
> UserAccessControlProvider handles users who dont have Jackrabbit managed
> Principals or User node inconsistently.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: JCR-2630
> URL: https://issues.apache.org/jira/browse/JCR-2630
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.0.0
> Reporter: Ian Boston
> Assignee: angela
> Fix For: 2.2.0
>
>
> JR core 2.0.0
> In UserAccessControlProvider.compilePermissions(...), if no principal
> relating to a user node can be found, then a set or read only compiled
> permissions is provided. That set gives the session read only access to the
> entire security workspace regardless of path.
> If the user node is found, then an instance of
> UserAccessControlProvider.CompilePermissions is used and in
> UserAccessControlProvider.CompilePermissions.buildResult(...) there is a
> check for no user node. If there is no user node, all permissions are denied
> regardless of path.
> Although the first case will never happen for an installation of Jackrabbit
> where there are no custom PrincipalManagers, I suspect, based on the impl of
> UserAccessControlProvider.CompilePermissions.buildResult(...) was to deny all
> access to the security workspace where there was no corresponding user node
> in a set of principals.
> Since this does not effect JR unless there is an external Principal Manager
> its a bit hard to produce a compact unit test, the issue was found by looking
> at the code.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
