You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Michael Stämpfli (JIRA)" <ji...@apache.org> on 2009/12/02 16:54:20 UTC

[jira] Created: (JCR-2420) Node removal fails

Node removal fails
------------------

                 Key: JCR-2420
                 URL: https://issues.apache.org/jira/browse/JCR-2420
             Project: Jackrabbit Content Repository
          Issue Type: Bug
          Components: jackrabbit-core, security
    Affects Versions: 1.6.0
            Reporter: Michael Stämpfli
            Priority: Blocker


I have a hierarchy of nodes which are all access controllable. The following hierarchy illustrates the setup for my problem.
root  -  read permissions to everyone
  | - subFolder  -  all permissions to user A
        | - subsubFolder  -  all permissions to user A

The user A has all rights from the node "subFolder" downwards.

I tried to remove the node "subsubFolder" with the user A. Clearly A has enough permissions to remove the node. But as soon as I call Session.save() an AccessDeniedException is thrown.

I did a lot of debugging and found a possible cause for this fault. It led me to the function ACLProvider.AclPermissions.buildResult(). All line references are based on the source code in the subversion repository found here: http://svn.apache.org/viewvc/jackrabbit/tags/1.6.0/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authorization/acl/ACLProvider.java?view=markup.
On line 458 Jackrabbit collects all access control entries of the node, that I want to remove, and all its parents and puts it in the variable "entries". In my example this variable contains three entries:
1. all permissions to user A
2. all permissions to user A
3. read permissions to everyone
On lines 460 - 466 it collects all access control entries of the node, that I want to remove, and puts it in "localACEs". This variable contains one entry: all permissions to user A.
If I want to be able to remove "subsubFolder", user A needs the permission from the parent node. The permissions of the parent nodes of "subsubFolder" are: all permissions to user A and read permissions to everyone. But that's where the access check fails. In line 488 Jackrabbit checks if a permission from "entries" is local or not by looking it up in "localACEs". If it is in there, the permission is local, else not. Unfortunately it recognizes the permission of the node "subFolder" as local. Thus the permissions of the parent nodes of "subsubFolder" are: read permissions to everyone. So I cannot remove the node.
The source of the error is the equals check of the access control entries. The permissions of node "subFolder" are considered equal to the one of "subsubFolder". If I explicitly assign the permission "remove node permission to user A" to the node "subFolder", it works fine, because it is recognized as parent permission.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-2420) Node removal fails with AccessDeniedException

Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting updated JCR-2420:
-------------------------------

    Fix Version/s: 2.0.3

> Node removal fails with AccessDeniedException
> ---------------------------------------------
>
>                 Key: JCR-2420
>                 URL: https://issues.apache.org/jira/browse/JCR-2420
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, security
>    Affects Versions: 1.6.0
>            Reporter: Michael Stämpfli
>            Assignee: angela
>            Priority: Blocker
>             Fix For: 2.0.3, 2.1.0
>
>
> I have a hierarchy of nodes which are all access controllable. The following hierarchy illustrates the setup for my problem.
> root  -  read permissions to everyone
>   | - subFolder  -  all permissions to user A
>         | - subsubFolder  -  all permissions to user A
> The user A has all rights from the node "subFolder" downwards.
> I tried to remove the node "subsubFolder" with the user A. Clearly A has enough permissions to remove the node. But as soon as I call Session.save() an AccessDeniedException is thrown.
> I did a lot of debugging and found a possible cause for this fault. It led me to the function ACLProvider.AclPermissions.buildResult(). All line references are based on the source code in the subversion repository found here: http://svn.apache.org/viewvc/jackrabbit/tags/1.6.0/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authorization/acl/ACLProvider.java?view=markup.
> On line 458 Jackrabbit collects all access control entries of the node, that I want to remove, and all its parents and puts it in the variable "entries". In my example this variable contains three entries:
> 1. all permissions to user A
> 2. all permissions to user A
> 3. read permissions to everyone
> On lines 460 - 466 it collects all access control entries of the node, that I want to remove, and puts it in "localACEs". This variable contains one entry: all permissions to user A.
> If I want to be able to remove "subsubFolder", user A needs the permission from the parent node. The permissions of the parent nodes of "subsubFolder" are: all permissions to user A and read permissions to everyone. But that's where the access check fails. In line 488 Jackrabbit checks if a permission from "entries" is local or not by looking it up in "localACEs". If it is in there, the permission is local, else not. Unfortunately it recognizes the permission of the node "subFolder" as local. Thus the permissions of the parent nodes of "subsubFolder" are: read permissions to everyone. So I cannot remove the node.
> The source of the error is the equals check of the access control entries. The permissions of node "subFolder" are considered equal to the one of "subsubFolder". If I explicitly assign the permission "remove node permission to user A" to the node "subFolder", it works fine, because it is recognized as parent permission.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-2420) Node removal fails with AccessDeniedException

Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Mueller updated JCR-2420:
--------------------------------

    Summary: Node removal fails with AccessDeniedException  (was: Node removal fails)

> Node removal fails with AccessDeniedException
> ---------------------------------------------
>
>                 Key: JCR-2420
>                 URL: https://issues.apache.org/jira/browse/JCR-2420
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, security
>    Affects Versions: 1.6.0
>            Reporter: Michael Stämpfli
>            Priority: Blocker
>
> I have a hierarchy of nodes which are all access controllable. The following hierarchy illustrates the setup for my problem.
> root  -  read permissions to everyone
>   | - subFolder  -  all permissions to user A
>         | - subsubFolder  -  all permissions to user A
> The user A has all rights from the node "subFolder" downwards.
> I tried to remove the node "subsubFolder" with the user A. Clearly A has enough permissions to remove the node. But as soon as I call Session.save() an AccessDeniedException is thrown.
> I did a lot of debugging and found a possible cause for this fault. It led me to the function ACLProvider.AclPermissions.buildResult(). All line references are based on the source code in the subversion repository found here: http://svn.apache.org/viewvc/jackrabbit/tags/1.6.0/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authorization/acl/ACLProvider.java?view=markup.
> On line 458 Jackrabbit collects all access control entries of the node, that I want to remove, and all its parents and puts it in the variable "entries". In my example this variable contains three entries:
> 1. all permissions to user A
> 2. all permissions to user A
> 3. read permissions to everyone
> On lines 460 - 466 it collects all access control entries of the node, that I want to remove, and puts it in "localACEs". This variable contains one entry: all permissions to user A.
> If I want to be able to remove "subsubFolder", user A needs the permission from the parent node. The permissions of the parent nodes of "subsubFolder" are: all permissions to user A and read permissions to everyone. But that's where the access check fails. In line 488 Jackrabbit checks if a permission from "entries" is local or not by looking it up in "localACEs". If it is in there, the permission is local, else not. Unfortunately it recognizes the permission of the node "subFolder" as local. Thus the permissions of the parent nodes of "subsubFolder" are: read permissions to everyone. So I cannot remove the node.
> The source of the error is the equals check of the access control entries. The permissions of node "subFolder" are considered equal to the one of "subsubFolder". If I explicitly assign the permission "remove node permission to user A" to the node "subFolder", it works fine, because it is recognized as parent permission.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-2420) Node removal fails with AccessDeniedException

Posted by "angela (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

angela resolved JCR-2420.
-------------------------

       Resolution: Fixed
    Fix Version/s: 2.1.0
         Assignee: angela

fixed with rev. 921394
thanks for reporting this issue.

> Node removal fails with AccessDeniedException
> ---------------------------------------------
>
>                 Key: JCR-2420
>                 URL: https://issues.apache.org/jira/browse/JCR-2420
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, security
>    Affects Versions: 1.6.0
>            Reporter: Michael Stämpfli
>            Assignee: angela
>            Priority: Blocker
>             Fix For: 2.1.0
>
>
> I have a hierarchy of nodes which are all access controllable. The following hierarchy illustrates the setup for my problem.
> root  -  read permissions to everyone
>   | - subFolder  -  all permissions to user A
>         | - subsubFolder  -  all permissions to user A
> The user A has all rights from the node "subFolder" downwards.
> I tried to remove the node "subsubFolder" with the user A. Clearly A has enough permissions to remove the node. But as soon as I call Session.save() an AccessDeniedException is thrown.
> I did a lot of debugging and found a possible cause for this fault. It led me to the function ACLProvider.AclPermissions.buildResult(). All line references are based on the source code in the subversion repository found here: http://svn.apache.org/viewvc/jackrabbit/tags/1.6.0/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authorization/acl/ACLProvider.java?view=markup.
> On line 458 Jackrabbit collects all access control entries of the node, that I want to remove, and all its parents and puts it in the variable "entries". In my example this variable contains three entries:
> 1. all permissions to user A
> 2. all permissions to user A
> 3. read permissions to everyone
> On lines 460 - 466 it collects all access control entries of the node, that I want to remove, and puts it in "localACEs". This variable contains one entry: all permissions to user A.
> If I want to be able to remove "subsubFolder", user A needs the permission from the parent node. The permissions of the parent nodes of "subsubFolder" are: all permissions to user A and read permissions to everyone. But that's where the access check fails. In line 488 Jackrabbit checks if a permission from "entries" is local or not by looking it up in "localACEs". If it is in there, the permission is local, else not. Unfortunately it recognizes the permission of the node "subFolder" as local. Thus the permissions of the parent nodes of "subsubFolder" are: read permissions to everyone. So I cannot remove the node.
> The source of the error is the equals check of the access control entries. The permissions of node "subFolder" are considered equal to the one of "subsubFolder". If I explicitly assign the permission "remove node permission to user A" to the node "subFolder", it works fine, because it is recognized as parent permission.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.