[
https://issues.apache.org/jira/browse/JCR-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-2630:
-------------------------------
Fix Version/s: 2.0.3
2.1.2
Merged to the 2.1 branch in revision 989591.
> 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.0.3, 2.1.2, 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.
