Uploaded image for project: 'Jackrabbit Content Repository'
  1. Jackrabbit Content Repository
  2. JCR-3451

Deleting a group node directly doesn't revoke cached memberships

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Invalid
    • Affects Version/s: 2.4
    • Fix Version/s: None
    • Component/s: security
    • Labels:
      None

      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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              hwong Honwai Wong
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: