Uploaded image for project: 'Sling'
  1. Sling
  2. SLING-8302

Sling Oak Restrictions - cannot apply allow permission for child node creation.



    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: Oak Restrictions 1.0.2
    • Fix Version/s: None
    • Component/s: Oak
    • Labels:


       I've run into a problem trying to get Sling permissions working for my use case. The simple case I'm trying right now is to allow a user 'alice' to have full access to all nodes at or below nodes with Sling resource type 'foo'.  Here's the test procedure I'm following:

      1. Fire up sling-starter 11 and log into the Composum browser as admin.
      2. Add a user 'alice'.
      3. Add permission jcr:read to '/' for alice so she can browse in Composum.
      4. Create a sling:Folder node '/content/data' with Sling resource type 'foo'.
      5. Create a sling:Folder node '/content/data/child1' with Sling resource type 'foo'.
      6. For the '/content/data' node, add a permission with principal 'alice', rule 'allow', privileges 'jcr:all', and restrictions 'sling:resourceTypesWithDescendants=foo'.
      7. In a separate browser, log in as alice and go to Composum.
      8. As alice, try to create the node '/content/data/child2'.

      Expected: User 'alice' can create the node.

      Actual: The Composum "Create New Node" dialog displays the error "Error 400 javax.jcr.AccessDeniedException: OakAccess0000: Access denied" and the node is not created.

       If I check effective permissions in Composum for /content/data and /content/data/child1, I see that 'alice' does receive jcr:all for both nodes.  Further, I can perform this check either as admin or alice, whereas I cannot look at permissions on /content as alice.

       If I try the Sling POST servlet as alice to create the node, I get a different exception "org.apache.sling.api.resource.PersistenceException: Resource at '/content/data/foo' is not modifiable."

      Georg Henzler duplicated the issue and provided the following explanation:

      I had a look and I could reproduce. I have used this module to hide existing nodes (denies), that's why I've never run into it.

      The root cause is that for the create case, not only [1] but also [2] gets called (since there is no tree available). ResourceTypePattern [3] always returns false in the same way as oak ootb NodeTypePattern [4]. So I'm not sure if we can even solve this, but I'd like to try, please create an issue in JIRA for this.

      [1] https://github.com/apache/jackrabbit-oak/blob/64a7e291c8dfd32ef36648ace0b0c6ee80780e2d/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/restriction/RestrictionPattern.java#L40

      [2] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/restriction/RestrictionPattern.java#L50

      [3] https://github.com/apache/sling-org-apache-sling-oak-restrictions/blob/8574518f43969db9e4f8bbeb4e825d6d05ee41f8/src/main/java/org/apache/sling/oak/restrictions/impl/ResourceTypePattern.java#L150

      [4] https://github.com/apache/jackrabbit-oak/blob/dc43f39e3203561542640218d2ec9a39c846ff2f/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L54





            • Assignee:
              nerff John Logan
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: