[
https://issues.apache.org/jira/browse/OAK-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669200#comment-13669200
]
Jukka Zitting commented on OAK-709:
-----------------------------------
I just realized a troublesome aspect of the rebase mechanism as discussed and
implemented above. Consider a (somewhat artificial, but still plausible) case
where someone would add an ACL that denies them read access to some parts of
the repository. To the current rebase mechanism this would look just as if
those parts of the repository would have been removed, which is the change that
the rebase would then apply to the underlying unsecured builder. :-(
To avoid this and other similar cases we may need to come up with a
SecureNodeBuilder class to accompany SecureNodeState. It would work just like
SNS in that it filters access to an underlying NodeBuilder instance. Any
modifications could be relayed directly to the underlying NodeBuilder, which
would allow us to avoid the current rebase step.
> Consider moving permission evaluation to the node state level
> -------------------------------------------------------------
>
> Key: OAK-709
> URL: https://issues.apache.org/jira/browse/OAK-709
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core
> Reporter: angela
> Attachments:
> 0001-OAK-709-Consider-moving-permission-evaluation-to-the.patch,
> 0001-OAK-709-Consider-moving-permission-evaluation-to-the.patch,
> 0001-OAK-709-Consider-moving-permission-evaluation-to-the.patch,
> 0001-OAK-709-Consider-moving-permission-evaluation-to-the.patch,
> OAK-709_2.patch, OAK-709_3.patch, OAK-709_4.patch, OAK-709-equals_hack.patch,
> OAK-709.patch, OAK-709-shadowing_nodes.patch, SecureNodeState.java
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
