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
[~rma61...@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)
