You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Angela Schreiber (Jira)" <ji...@apache.org> on 2023/06/06 14:51:00 UTC

[jira] [Created] (OAK-10269) TreePermissionImpl.canRead(PropertyState) doesn't check READ_ACCESS_CONTROL for isolated property

Angela Schreiber created OAK-10269:
--------------------------------------

             Summary: TreePermissionImpl.canRead(PropertyState) doesn't check READ_ACCESS_CONTROL for isolated property
                 Key: OAK-10269
                 URL: https://issues.apache.org/jira/browse/OAK-10269
             Project: Jackrabbit Oak
          Issue Type: Bug
          Components: core, security
            Reporter: Angela Schreiber


[~rma61870@adobe.com] spotted an issue with {{TreePermissionImpl.canRead(PropertyState)}} in a customized authorization setup that defines isolated access control properties that are not located with a access controlled node.
h3. Setup
 - define a custom authorization model that comes with a {{Context}} implementation marking isolated properties as access control content without having the parent node be access controlled (i.e. outside of a policy node)
 - plug the authorization model into an oak security setup
 - grant a test user read access to the tree where the isolated ac-properties are defined, but don't grant {{jcr:readAccessControl}} privilege
 - testing {{Session.hasPermission}} for the isolated properties returns the expected result
 - however, the test session is able to read the property with just regular read-access granted
 - writing the property only works if {{jcr:modifyAccessControl}} privilege is granted (as expected)

h3. Analysis

{{TreePermissionImpl#canRead(Property)}} [1] verifies if the parent tree is access controlled and does not check if the property itself is access control outside of an access controlled tree. In other words: isolated access control properties that are not below an access controlled tree, will not be found to be access control content.

All access control properties shipped with Oak are associated with an access control policy node. The issue therefore only applies to custom models that
 - define isolated access control properties
 - rely on the the default authorization model to enforce READ_ACCESS_CONTROL permission

h3. Next steps

The fix for TreePermissionImpl#canRead(Property) itself would be straight forward, but I have 2 concerns:
 - we need to evaluate if that's the only place where the code expects all access controlled properties to be located below an access controlled node
 - additional checking the ac-status of every single property (instead of just relying on the Tree-type of the parent may impact overall read performance and extra benchmarks will be needed to assess that.

Unless we have an urgent need to get this fixed, I would therefore suggest to document the current behavior as know limitation of the default authorization model.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)