TreePermissionImpl.canRead(PropertyState) doesn't check READ_ACCESS_CONTROL for isolated property

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.

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)

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

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.