You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Honwai Wong (JIRA)" <ji...@apache.org> on 2012/10/23 12:05:11 UTC
[jira] [Created] (JCR-3451) Deleting a group node directly doesn't
revoke cached memberships
Honwai Wong created JCR-3451:
--------------------------------
Summary: Deleting a group node directly doesn't revoke cached memberships
Key: JCR-3451
URL: https://issues.apache.org/jira/browse/JCR-3451
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: security
Affects Versions: 2.4
Reporter: Honwai Wong
If a group node is deleted directly (e.g. beneath /home/groups) via the JCR API, previously effective group memberships are not revoked and purged consistently from the membership cache. This is potentially a security risk where inherited permissions from indirect group-memberships will become effective.
Following the use-case:
- create user testuser
- create group testgroup
- make testuser member of testgroup
- deny read access for testgroup on /content/xyz
- create another group parentgroup
- allow read access for parentgroup on /content/xyz
- make testgroup member of parentgroup
--> at this point, testuser doesn't have read access to /content/xyz
- delete testgroup by removing the corresponding group node in the repository (e.g. /home/groups/t/testgroup)
--> testuser has read access to /content/xyz !
What seems to be missing is a call to org.apache.jackrabbit.api.security.user.Authorizable#remove which ultimately triggers the ClearMembershipAction to take care of cleaning up stale group memberships. A potential solution would be to implement an observation based approach to catch node removals of group nodes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCR-3451) Deleting a group node directly doesn't
revoke cached memberships
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela resolved JCR-3451.
-------------------------
Resolution: Invalid
if you remove a user/group node directly instead of using user management API, you are in charge
of clearing/updating the membership yourself.
i don't think that this something jackrabbit needs to deal with in the first place (except for making the
user/group hierarchy protected again which would need a separate discussion).
> Deleting a group node directly doesn't revoke cached memberships
> ----------------------------------------------------------------
>
> Key: JCR-3451
> URL: https://issues.apache.org/jira/browse/JCR-3451
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: security
> Affects Versions: 2.4
> Reporter: Honwai Wong
>
> If a group node is deleted directly (e.g. beneath /home/groups) via the JCR API, previously effective group memberships are not revoked and purged consistently from the membership cache. This is potentially a security risk where inherited permissions from indirect group-memberships will become effective.
> Following the use-case:
> - create user testuser
> - create group testgroup
> - make testuser member of testgroup
> - deny read access for testgroup on /content/xyz
> - create another group parentgroup
> - allow read access for parentgroup on /content/xyz
> - make testgroup member of parentgroup
> --> at this point, testuser doesn't have read access to /content/xyz
> - delete testgroup by removing the corresponding group node in the repository (e.g. /home/groups/t/testgroup)
> --> testuser has read access to /content/xyz !
> What seems to be missing is a call to org.apache.jackrabbit.api.security.user.Authorizable#remove which ultimately triggers the ClearMembershipAction to take care of cleaning up stale group memberships. A potential solution would be to implement an observation based approach to catch node removals of group nodes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira