Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <10787875.100341274169285687.JavaMail.jira@thor>
Date: Tue, 18 May 2010 03:54:45 -0400 (EDT)
From: "angela (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Updated: (JCR-2630) UserAccessControlProvider handles users
 who dont have Jackrabbit managed Principals or User node inconsistently.
In-Reply-To: <27927942.40641273827106121.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

angela updated JCR-2630:
------------------------

    Summary: UserAccessControlProvider handles users who dont have Jackrabbit managed Principals or User node inconsistently.  (was: UserAccessControlProvider handles users who dont have Jackrabbit managed Principals or User node incosistently.)

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