jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (JCR-2630) UserAccessControlProvider handles users who dont have Jackrabbit managed Principals or User node inconsistently.
Date Tue, 18 May 2010 07:56:45 GMT

     [ 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.


Mime
View raw message