[JCR-3451] Deleting a group node directly doesn't revoke cached memberships

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Invalid
• Affects Version/s: 2.4
• Component/s: security
• Assignee: Unassigned
• Reporter: Honwai Wong
• Created: 23/Oct/12 10:04
• Updated: 06/May/13 11:13
• Resolved: 23/Oct/12 10:46

Description

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.