jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Accessibility of NodeTypes, Privileges and Namespaces
Date Mon, 22 Apr 2013 09:52:34 GMT
hi jukka

i am not talking about commit hooks but rather about regular
JCR item access and write operations with a non-admin session.

there we can't guarantee that a given session as full read
permission on the complete tree and may even face the situation
were read access is only granted in given subtree. that's the
use case i am referring to and it's only here where we violate
backwards compatibility if that session can't read on the
mentioned subtrees underneath jcr:system. as far as i remember
the specification doesn't make any statements regarding
restricted access to namespaces or nodetypes, so we may look
for the solution that fits our needs the best.

if we can agree on a backwards compatible setup, the easiest thing
probably was to allow read access for node types, namespaces and
privileges without having to create a separated ACL for all of

kind regards

On 4/22/13 11:02 AM, Jukka Zitting wrote:
> Hi,
> On Mon, Apr 22, 2013 at 11:22 AM, Angela Schreiber<anchela@adobe.com>  wrote:
>> now, as of oak all of them are stored and accessed in the repository
>> and are consequently affected by regular item read access which
>> basically breaks backwards compatibility.
> Note that the commit hooks and things like search indices work below
> access controls, so they can in any case see the full /jcr:system
> subtree and any repository metadata stored there.
> The only bits that would be affected in the odd case where an
> administrator would deny read access to something like the
> /jcr:system/jcr:nodeTypes subtree would be the JCR-level
> NodeTypeRegistry implementation and related methods. That might well
> break some clients, but so would an administrator explicitly modifying
> the builtin nodetypes file in Jackrabbit 2.x.
> So at best I'd simply document that to keep an Oak repository
> backwards compatible and JCR compliant, one shouldn't apply extra read
> access controls on the repository metadata stored under /jcr:system.
> There shouldn't be any need to explicitly enforce that in code.
> If needed, I wouldn't be opposed to having an explicit access control
> entry in /jcr:system that grants everyone read access to that subtree,
> excluding version histories and other sensitive areas that in any case
> are handled separately. Ideally I don't think that should be needed
> though, as IMO content should be readable by default, unless
> explicitly denied by access control.
> BR,
> Jukka Zitting

View raw message