[
https://issues.apache.org/jira/browse/OAK-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632700#comment-15632700
]
angela commented on OAK-4959:
-----------------------------
[~chetanm], the 2 topics you mention are slightly different:
h5. Writable using JCR API
this is the default unless you use a node type that defines protected items
_or_ have some Oak internal hook that prevents writing such as we have e.g. for
the trees below {{/jcr:system/jcr:versionStorage}} and
{{/jcr:system/rep:permissionStore}}.
h5. Updatetable only by System Admin
this is something that comes up every now and then when we have to secure
subtrees that are not expected to be written by regular user. the issue with an
access-control based approach is that you cannot reliably limit permissions to
a system admin for various reason:
a) the permission setup might be (unintentionally) change at runtime,
b) depending on the authorization model a given policy or access control entry
may not have the desired effect due to the way the effective permissions are
calculated and the individual pieces are weighted. think of an ACE for the
Everyone group principal showing no effect due to an entry for a user-principal
that takes precedence. or another example, deploying an additional
authorization model may change the effective permissions in an unexpected way.
I had similar needs not only for the permission store mentioned above but also
for other system-owned content, which at the same time needed to be writable
(or at least removable) using Oak/Jcr API calls: login tokens, principal-cache
with user-management, {{rep:externalId}} and {{rep:externalPrincipalNames}}
associated with synchronized user accounts. in all these cases I ended up
providing a dedicated {{ValidatorProvider}} that ensures that writing sensitive
content is only added|modified|removed by a narrow set of subjects or through a
dedicated API.
You may want to take a look at {{ExternalIdentityValidatorProvider}} which
enforces protection of 2 properties: one that is only written by the internal
system and one that might also be written by regular users e.g. through XML
import.
h5. Defining System Admin
One more comment regarding the notion of 'system admin': this term is used for
different things and it depends a bit on your setup and your requirements on
whether this refers to the Oak internal system administration or to a
combination of internal system administration plus administrative user(s) that
are in charge of setting up additional parts of the repository. Something like
a) internal system session (=> see e.g. {{CacheValidator}} in the user
management and {{rep:externalPrincipalNames}}; write is limited to
{{SystemPrincipal}})
b) internal system-session + admin user (=> no example in Oak; write limited to
{{SystemPrincipal}} and {{AdminPrincipal}})
c) internal system-session + admin user + configured administrators-principals
(=> write limited to {{SystemPrincipal}} and {{AdminPrincipal}} and configured
principal-names; see {{PermissionUtil.isAdminOrSystem}} for an example).
Hope that helps
> Review the security aspect of bundling configuration
> ----------------------------------------------------
>
> Key: OAK-4959
> URL: https://issues.apache.org/jira/browse/OAK-4959
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: documentmk
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Labels: bundling
> Fix For: 1.6
>
>
> The config for node bundling feature in DocumentNodeStore is currently stored
> under {{jcr:system/rep:documentStore/bundlor}}. This task is meant to
> * Review the access control aspect - This config should be only updatetable
> by system admin
> * Config under here should be writeable via JCR api
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
