Accessibility of NodeTypes, Privileges and Namespaces

[Angela Schreiber <an...@adobe.com>]

hi

in jackrabbit-core node types, namespaces and privileges were stored
separated from the repository content in the file system. accessibility
of that part of the repository was therefore never managed by the
regular item access in jackrabbit.

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.

i see the following ways we could address this:

a) setup full read access for the corresponding content trees in oak
b) define separate default access control policies for those trees that
    are present irrespective of the ac policies defined in the content.
    sort of "post-evaluation" rule that always takes effect.

not doing anything and leaving setup of these access rights to the
users doesn't see to be the wright solution to me.

see also https://issues.apache.org/jira/browse/OAK-787

kind regards
angela

Re: Accessibility of NodeTypes, Privileges and Namespaces

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Mon, Apr 22, 2013 at 2:45 PM, Angela Schreiber <an...@adobe.com> wrote:
> On 4/22/13 1:37 PM, Jukka Zitting wrote:
>> Wouldn't an ACL on the /jcr:system subtree override one on the root node?
>
> it would as long as only aces for group principals are used.
> but user principals take precedence over group principals...

Right.

> maybe... but if this kind of access is *always* required there
> is not much benefit in making it look as if it could be edited.
> more to come in the issue...

Fair enough. The patch looks good to me.

BR,

Jukka Zitting

Re: Accessibility of NodeTypes, Privileges and Namespaces

[Angela Schreiber <an...@adobe.com>]

On 4/22/13 1:37 PM, Jukka Zitting wrote:
> Hi,
>
> On Mon, Apr 22, 2013 at 2:14 PM, Angela Schreiber<an...@adobe.com>  wrote:
>> that's basically my proposal a) but i am not totally sure if that's
>> the best solution... in particular it will not work if someone
>> would deny read-access to a 'user' on the root node...
>
> Wouldn't an ACL on the /jcr:system subtree override one on the root node?

it would as long as only aces for group principals are used.
but user principals take precedence over group principals...

>> in addition
>> i am not sure, if we really want to have full/regular ac-evaluation
>> for those trees...
>
> I don't see much harm in having them under normal access control.

no harm. but it feels strange to me... and it might also be
troublesome when it comes to upgrading an existing repository.

> Did
> you have something specific in mind? On the contrary, avoiding a
> special case for this should help keep the relevant code simple.

maybe... but if this kind of access is *always* required there
is not much benefit in making it look as if it could be edited.
more to come in the issue...

angela

> BR,
>
> Jukka Zitting

Re: Accessibility of NodeTypes, Privileges and Namespaces

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Mon, Apr 22, 2013 at 2:14 PM, Angela Schreiber <an...@adobe.com> wrote:
> that's basically my proposal a) but i am not totally sure if that's
> the best solution... in particular it will not work if someone
> would deny read-access to a 'user' on the root node...

Wouldn't an ACL on the /jcr:system subtree override one on the root node?

> in addition
> i am not sure, if we really want to have full/regular ac-evaluation
> for those trees...

I don't see much harm in having them under normal access control. Did
you have something specific in mind? On the contrary, avoiding a
special case for this should help keep the relevant code simple.

BR,

Jukka Zitting

Re: Accessibility of NodeTypes, Privileges and Namespaces

[Angela Schreiber <an...@adobe.com>]

hi jukka

> How about my suggestion of including a default ACL on /jcr:system that
> grants read permission to that subtree to everyone, regardless of what
> access controls are defined on the root node?

that's basically my proposal a) but i am not totally sure if that's
the best solution... in particular it will not work if someone
would deny read-access to a 'user' on the root node... in addition
i am not sure, if we really want to have full/regular ac-evaluation
for those trees... anyway... i will try it and attach patches to
the issue.

regards
angela

Re: Accessibility of NodeTypes, Privileges and Namespaces

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Mon, Apr 22, 2013 at 12:52 PM, Angela Schreiber <an...@adobe.com> wrote:
> i am not talking about commit hooks but rather about regular
> JCR item access and write operations with a non-admin session.

ACK.

> 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
> those.

How about my suggestion of including a default ACL on /jcr:system that
grants read permission to that subtree to everyone, regardless of what
access controls are defined on the root node?

BR,

Jukka Zitting

Re: Accessibility of NodeTypes, Privileges and Namespaces

[Angela Schreiber <an...@adobe.com>]

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
those.

kind regards
angela

On 4/22/13 11:02 AM, Jukka Zitting wrote:
> Hi,
>
> On Mon, Apr 22, 2013 at 11:22 AM, Angela Schreiber<an...@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

Re: Accessibility of NodeTypes, Privileges and Namespaces

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Mon, Apr 22, 2013 at 11:22 AM, Angela Schreiber <an...@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