2 Replies Latest reply on Dec 6, 2012 10:05 PM by Pradeep Jatrana

    Permission Inheritance Problem

    Ryan Lunka Level 3

      My client is having an issue with permission inheritance down their page tree.  Here's a small sample of the page hierachy we are dealing with:

       

      • F0 (sling:OrderedFolder)
        • F1 (sling:OrderedFolder)
          • jcr:content (nt:unstructured)
          • P1 (cq:Page)
          • P2 (cq:Page)
          • P3 (cq:Page)

       

      We need to be able to ALLOW the "modify" and "create" actions for F0 and have it inherit all the way down through the pages.  However, when we do this, the inheritance for "modify" stops after F1.  F0 will allow "modify" (this is where we set ALLOW).  F1 will allow it.  F1's jcr:content node will allow it.  None of the children of F1 that are pages will allow "modify".  However, the "create" action will inherit all the way down through just fine.

       

      It gets weirder.  If we add ALLOW "delete" to F0 it fixes the problem.  All three of the actions inherit all the way down through.  So we tried setting them one at a time.  Setting just "delete" inherits all the way down through.  Setting just "create" does too.  Setting just "modify" does not work.  It has the same unexpected behavior where the cq:Page nodes do not inherit the permission.

       

      I'm not completely convinced this is a product bug because it only happens in the client's application.  I tried to replicate the same scenario on a standalone instance on my dev machine using the Geometrixx site and everything worked as expected.  So I'm looking for some feedback...

       

      Is there something about the permission model that I'm not thinking about correctly that would explain this behavior?  Are there any node-types, properties, etc. that I should be looking out for (maybe something that has given you trouble in the past)?  Really I would appreciate any feedback on the issue, because this is a pretty strange one.  I plan to cross post this to the Google Group as well.  Thanks a lot!

        • 1. Re: Permission Inheritance Problem
          hypnotec Adobe Employee

          are you sure the client doesn't have some "globbing" ACLs set e.g. on "/" (the root node)? best check with CRX explorer and provide screenshots of every node of the path to F1 and e.g. P3.

          • 2. Re: Permission Inheritance Problem
            Pradeep Jatrana

            I was facing the same issue and solved by setting below permissions

            In our case "editors" are only allowed to modify pages, but not allowed to delete pages. So we intially set below permission on path:

             

            "/content" --> rep:privileges="{Name}[jcr:modifyProperties,jcr:addChildNodes,jcr:nodeTypeManagement,jcr: versionManagement,jcr:lockManagement]"/> (This works in 5.4 but fails in 5.5)

             

            With these permissions the modify property was not inherited by the child nodes of page type. Reason:: because in order to modify pages, Addition and Deletion of "jcr:content" child nodes is required. So we need to set jcr:removeChildNodes,jcr:removeNode permission for jcr:content nodes and its child nodes.

             

            By setting below permission, the "modify" was inherited by all "content" node children:

             

            These permission I placed in a _rep_policy.xml file under "/content" folder of my package archive

             

            <allow

                    jcr:primaryType="rep:GrantACE"

                    rep:principalName="editors"

                     rep:privileges="{Name}[jcr:addChildNodes,jcr:nodeTypeManagement,jcr:lockManagement,jcr:mo difyProperties,jcr:versionManagement]"/>

            <allow5

                    jcr:primaryType="rep:GrantACE"

                    rep:glob="*/jcr:content*"

                    rep:principalName="editors"

                    rep:privileges="{Name}[jcr:removeChildNodes,jcr:removeNode]"/>

             

            - Pradeep Rana