Re: ACL on versioned node

[Marco Piovesana <pi...@esteco.com>]

Hi Angela,
thanks for the clarification, I thought the access control content was
versioned alongside the node. If you don't mind me asking I have another
question though (that might be a little off topic): why is required to
version a node to change its access control information if the access
control information is not part of the version information? If I restore a
node to a previous version (that had different permission settings), the
permission on the node are not restored alongside the node state, so why do
I have to version it in the first place? Am I missing something?

Marco.

On Wed, Oct 31, 2018 at 2:03 PM Angela Schreiber <an...@adobe.com.invalid>
wrote:

> Hi Marco
>
> As far as I remember the access control content is not versioned along
> with the parent node it is attached to in the default implementation. This
> is indeed due to the OPV flag set to IGNORE with the corresponding node
> type definitions. However that cannot be changed and it is somewhat
> unrelated to the issue you are seeing (i.e. the read only status of a
> checked-in node). The OPV defines what happens to an item in the subtree of
> a versionable node upon checkin i.e. the creation of a new version and
> which imformation also makes it in which form to the version storage
> (IGNORE: not copied to version storage at all). It also has an impact on
> restore. You will find all the details in the specification.
>
> Kind regards
> Angela
> ________________________________________
> From: Marco Piovesana <pi...@esteco.com>
> Sent: Wednesday, October 31, 2018 9:53 AM
> To: oak-dev@jackrabbit.apache.org
> Subject: Re: ACL on versioned node
>
> Sure,
> I'll add a JIRA for it with the test case. One more question, if I want to
> separate the versioning of the node from the permission policy on it, can I
> set the OPV to ignore for the relative rep:policy node? Or that just
> doesn't work?
>
> Marco
>
> On Wed, Oct 31, 2018 at 8:52 AM Angela Schreiber <anchela@adobe.com.invalid
> >
> wrote:
>
> > Hi Marco
> >
> > Upon checkin of a versionable node (and it's non-versionable subtree)
> > becomes read-only. I think the first behavior is a bug.  Changing
> > permissions of a checked-in node should not be possible. The reason why
> you
> > are seeing it in the second case is due to the fact that a mixin is
> > automatically added to the checked-in node. But also the modification of
> > access control content in the subtree should trigger the exception (which
> > it doesn't apparently)
> >
> > Here a quote from the specification:
> > The node N and its connected non-versionable subtree become read-only.
> N's
> > connected non-versionable subtree is the set of non-versionable
> descendant
> > nodes reachable from N through child links without encountering any
> > versionable nodes. In other words, the read-only status flows down from
> the
> > checked-in node along every child link until either a versionable node is
> > encountered or an item with no children is encountered.
> >
> > Since the policy node and the access controlled content stored therein is
> > not versionable the checkin status of it's versionable parent (or
> ancestor
> > for that matter) should be enforced.
> >
> > May I ask you to create a JIRA ticket for that?
> > Thanks
> > Angela
> >
> > ________________________________________
> > From: Marco Piovesana <pi...@esteco.com>
> > Sent: Tuesday, October 30, 2018 7:05 PM
> > To: oak-dev@jackrabbit.apache.org
> > Subject: ACL on versioned node
> >
> > Hi all,
> > I'm using Oak 1.8.1 and I don't think I fully understand how permissions
> > are handled in versioned nodes.
> >
> > If I create the first version of a node *after* adding an ACE to it,
> then I
> > can add or remove other ACE without having to checkout the node.
> >
> > If I create the first version of the node *before* adding the first ACE,
> > then I get the error (*OakVersion0001: Cannot change property
> > jcr:mixinTypes on checked in node*) whenever i try to modify the node
> > permissions without checking it out first.
> >
> > what is the expected behavior? Checkout should be required or not to
> modify
> > the user's permission on the node?
> >
> > Marco.
>

Re: ACL on versioned node

[Alex Deparvu <st...@apache.org>]

Hi,

Could this be related to adding the "rep:AccessControllable" mixin if it
doesn't exist on that specific node?
(The AccessControlManagerImpl will update the mixins property in the case
it is not there.)

It fits with the examples:

> If I create the first version of a node *after* adding an ACE to it, then
I can add or remove other ACE without having to checkout the node.
in this case the mixin was already added prior to the versioning operation,
so adding/removing ACEs will not touch the mixin

> If I create the first version of the node *before* adding the first ACE,
then I get the error (*OakVersion0001: Cannot change property
jcr:mixinTypes on checked in node*) whenever i try to modify the node
permissions without checking it out first.
In this case touching the mixins would trigger the version validation on
the mixing requiring a checkout/checkin of that node.


best,
alex

On Fri, Nov 2, 2018 at 4:03 PM Marco Piovesana <pi...@esteco.com> wrote:

> Hi Angela,
> let me try to rephrase my followup question. I have a versioned node and I
> need to change the permissions a user has on that node.
> If I try to modify the access control without checking-out the node I got
> the error: *OakVersion0001: Cannot change property jcr:mixinTypes on
> checked in node.* So, I ended up creating a new version each time I want to
> modify the node ACL.
> From this exchange of email I was under the impression that a
> checkout/checkin is required when changing the node's ACL and I was
> wondering why, since the access control is not part of the node versioned
> information (and not something is restored when restoring a node to a
> previous version).
>
> Marco.
>
> On Fri, Nov 2, 2018 at 3:40 PM Angela Schreiber <anchela@adobe.com.invalid
> >
> wrote:
>
> > Hi Marco
> >
> > Regarding your original question I found, that I was actually mistaken
> :-)
> > See OAK-6015 for the reason why IGNORED nodes are treated differently.
> >
> > Not sure thought I understand your followup question... you don't need to
> > make a node versionable or version it in order to place/edit access
> control
> > information on it. But the fact that ac-content is marked with OPV IGNORE
> > is an implementation detail. See also
> >
> http://jackrabbit.apache.org/oak/docs/security/permission/differences.html
> > for details on how access to the version storage is evaluated.
> >
> > Kind regards
> > Angela
> > ________________________________________
> > From: Marco Piovesana <pi...@esteco.com>
> > Sent: Friday, November 2, 2018 3:23 PM
> > To: oak-dev@jackrabbit.apache.org
> > Subject: Re: ACL on versioned node
> >
> > Hi Angela,
> > thanks for the clarification, I thought the access control content was
> > versioned alongside the node. If you don't mind me asking I have another
> > question though (that might be a little off topic): why is required to
> > version a node to change its access control information if the access
> > control information is not part of the version information? If I restore
> a
> > node to a previous version (that had different permission settings), the
> > permission on the node are not restored alongside the node state, so why
> do
> > I have to version it in the first place? Am I missing something?
> >
> > Marco.
> >
> > On Wed, Oct 31, 2018 at 2:03 PM Angela Schreiber
> <anchela@adobe.com.invalid
> > >
> > wrote:
> >
> > > Hi Marco
> > >
> > > As far as I remember the access control content is not versioned along
> > > with the parent node it is attached to in the default implementation.
> > This
> > > is indeed due to the OPV flag set to IGNORE with the corresponding node
> > > type definitions. However that cannot be changed and it is somewhat
> > > unrelated to the issue you are seeing (i.e. the read only status of a
> > > checked-in node). The OPV defines what happens to an item in the
> subtree
> > of
> > > a versionable node upon checkin i.e. the creation of a new version and
> > > which imformation also makes it in which form to the version storage
> > > (IGNORE: not copied to version storage at all). It also has an impact
> on
> > > restore. You will find all the details in the specification.
> > >
> > > Kind regards
> > > Angela
> > > ________________________________________
> > > From: Marco Piovesana <pi...@esteco.com>
> > > Sent: Wednesday, October 31, 2018 9:53 AM
> > > To: oak-dev@jackrabbit.apache.org
> > > Subject: Re: ACL on versioned node
> > >
> > > Sure,
> > > I'll add a JIRA for it with the test case. One more question, if I want
> > to
> > > separate the versioning of the node from the permission policy on it,
> > can I
> > > set the OPV to ignore for the relative rep:policy node? Or that just
> > > doesn't work?
> > >
> > > Marco
> > >
> > > On Wed, Oct 31, 2018 at 8:52 AM Angela Schreiber
> > <anchela@adobe.com.invalid
> > > >
> > > wrote:
> > >
> > > > Hi Marco
> > > >
> > > > Upon checkin of a versionable node (and it's non-versionable subtree)
> > > > becomes read-only. I think the first behavior is a bug.  Changing
> > > > permissions of a checked-in node should not be possible. The reason
> why
> > > you
> > > > are seeing it in the second case is due to the fact that a mixin is
> > > > automatically added to the checked-in node. But also the modification
> > of
> > > > access control content in the subtree should trigger the exception
> > (which
> > > > it doesn't apparently)
> > > >
> > > > Here a quote from the specification:
> > > > The node N and its connected non-versionable subtree become
> read-only.
> > > N's
> > > > connected non-versionable subtree is the set of non-versionable
> > > descendant
> > > > nodes reachable from N through child links without encountering any
> > > > versionable nodes. In other words, the read-only status flows down
> from
> > > the
> > > > checked-in node along every child link until either a versionable
> node
> > is
> > > > encountered or an item with no children is encountered.
> > > >
> > > > Since the policy node and the access controlled content stored
> therein
> > is
> > > > not versionable the checkin status of it's versionable parent (or
> > > ancestor
> > > > for that matter) should be enforced.
> > > >
> > > > May I ask you to create a JIRA ticket for that?
> > > > Thanks
> > > > Angela
> > > >
> > > > ________________________________________
> > > > From: Marco Piovesana <pi...@esteco.com>
> > > > Sent: Tuesday, October 30, 2018 7:05 PM
> > > > To: oak-dev@jackrabbit.apache.org
> > > > Subject: ACL on versioned node
> > > >
> > > > Hi all,
> > > > I'm using Oak 1.8.1 and I don't think I fully understand how
> > permissions
> > > > are handled in versioned nodes.
> > > >
> > > > If I create the first version of a node *after* adding an ACE to it,
> > > then I
> > > > can add or remove other ACE without having to checkout the node.
> > > >
> > > > If I create the first version of the node *before* adding the first
> > ACE,
> > > > then I get the error (*OakVersion0001: Cannot change property
> > > > jcr:mixinTypes on checked in node*) whenever i try to modify the node
> > > > permissions without checking it out first.
> > > >
> > > > what is the expected behavior? Checkout should be required or not to
> > > modify
> > > > the user's permission on the node?
> > > >
> > > > Marco.
> > >
> >
>

Re: ACL on versioned node

[Marco Piovesana <pi...@esteco.com>]

Hi Angela,
let me try to rephrase my followup question. I have a versioned node and I
need to change the permissions a user has on that node.
If I try to modify the access control without checking-out the node I got
the error: *OakVersion0001: Cannot change property jcr:mixinTypes on
checked in node.* So, I ended up creating a new version each time I want to
modify the node ACL.
From this exchange of email I was under the impression that a
checkout/checkin is required when changing the node's ACL and I was
wondering why, since the access control is not part of the node versioned
information (and not something is restored when restoring a node to a
previous version).

Marco.

On Fri, Nov 2, 2018 at 3:40 PM Angela Schreiber <an...@adobe.com.invalid>
wrote:

> Hi Marco
>
> Regarding your original question I found, that I was actually mistaken :-)
> See OAK-6015 for the reason why IGNORED nodes are treated differently.
>
> Not sure thought I understand your followup question... you don't need to
> make a node versionable or version it in order to place/edit access control
> information on it. But the fact that ac-content is marked with OPV IGNORE
> is an implementation detail. See also
> http://jackrabbit.apache.org/oak/docs/security/permission/differences.html
> for details on how access to the version storage is evaluated.
>
> Kind regards
> Angela
> ________________________________________
> From: Marco Piovesana <pi...@esteco.com>
> Sent: Friday, November 2, 2018 3:23 PM
> To: oak-dev@jackrabbit.apache.org
> Subject: Re: ACL on versioned node
>
> Hi Angela,
> thanks for the clarification, I thought the access control content was
> versioned alongside the node. If you don't mind me asking I have another
> question though (that might be a little off topic): why is required to
> version a node to change its access control information if the access
> control information is not part of the version information? If I restore a
> node to a previous version (that had different permission settings), the
> permission on the node are not restored alongside the node state, so why do
> I have to version it in the first place? Am I missing something?
>
> Marco.
>
> On Wed, Oct 31, 2018 at 2:03 PM Angela Schreiber <anchela@adobe.com.invalid
> >
> wrote:
>
> > Hi Marco
> >
> > As far as I remember the access control content is not versioned along
> > with the parent node it is attached to in the default implementation.
> This
> > is indeed due to the OPV flag set to IGNORE with the corresponding node
> > type definitions. However that cannot be changed and it is somewhat
> > unrelated to the issue you are seeing (i.e. the read only status of a
> > checked-in node). The OPV defines what happens to an item in the subtree
> of
> > a versionable node upon checkin i.e. the creation of a new version and
> > which imformation also makes it in which form to the version storage
> > (IGNORE: not copied to version storage at all). It also has an impact on
> > restore. You will find all the details in the specification.
> >
> > Kind regards
> > Angela
> > ________________________________________
> > From: Marco Piovesana <pi...@esteco.com>
> > Sent: Wednesday, October 31, 2018 9:53 AM
> > To: oak-dev@jackrabbit.apache.org
> > Subject: Re: ACL on versioned node
> >
> > Sure,
> > I'll add a JIRA for it with the test case. One more question, if I want
> to
> > separate the versioning of the node from the permission policy on it,
> can I
> > set the OPV to ignore for the relative rep:policy node? Or that just
> > doesn't work?
> >
> > Marco
> >
> > On Wed, Oct 31, 2018 at 8:52 AM Angela Schreiber
> <anchela@adobe.com.invalid
> > >
> > wrote:
> >
> > > Hi Marco
> > >
> > > Upon checkin of a versionable node (and it's non-versionable subtree)
> > > becomes read-only. I think the first behavior is a bug.  Changing
> > > permissions of a checked-in node should not be possible. The reason why
> > you
> > > are seeing it in the second case is due to the fact that a mixin is
> > > automatically added to the checked-in node. But also the modification
> of
> > > access control content in the subtree should trigger the exception
> (which
> > > it doesn't apparently)
> > >
> > > Here a quote from the specification:
> > > The node N and its connected non-versionable subtree become read-only.
> > N's
> > > connected non-versionable subtree is the set of non-versionable
> > descendant
> > > nodes reachable from N through child links without encountering any
> > > versionable nodes. In other words, the read-only status flows down from
> > the
> > > checked-in node along every child link until either a versionable node
> is
> > > encountered or an item with no children is encountered.
> > >
> > > Since the policy node and the access controlled content stored therein
> is
> > > not versionable the checkin status of it's versionable parent (or
> > ancestor
> > > for that matter) should be enforced.
> > >
> > > May I ask you to create a JIRA ticket for that?
> > > Thanks
> > > Angela
> > >
> > > ________________________________________
> > > From: Marco Piovesana <pi...@esteco.com>
> > > Sent: Tuesday, October 30, 2018 7:05 PM
> > > To: oak-dev@jackrabbit.apache.org
> > > Subject: ACL on versioned node
> > >
> > > Hi all,
> > > I'm using Oak 1.8.1 and I don't think I fully understand how
> permissions
> > > are handled in versioned nodes.
> > >
> > > If I create the first version of a node *after* adding an ACE to it,
> > then I
> > > can add or remove other ACE without having to checkout the node.
> > >
> > > If I create the first version of the node *before* adding the first
> ACE,
> > > then I get the error (*OakVersion0001: Cannot change property
> > > jcr:mixinTypes on checked in node*) whenever i try to modify the node
> > > permissions without checking it out first.
> > >
> > > what is the expected behavior? Checkout should be required or not to
> > modify
> > > the user's permission on the node?
> > >
> > > Marco.
> >
>

Re: ACL on versioned node

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

Hi Marco

Regarding your original question I found, that I was actually mistaken :-) See OAK-6015 for the reason why IGNORED nodes are treated differently.

Not sure thought I understand your followup question... you don't need to make a node versionable or version it in order to place/edit access control information on it. But the fact that ac-content is marked with OPV IGNORE is an implementation detail. See also http://jackrabbit.apache.org/oak/docs/security/permission/differences.html for details on how access to the version storage is evaluated.

Kind regards
Angela
________________________________________
From: Marco Piovesana <pi...@esteco.com>
Sent: Friday, November 2, 2018 3:23 PM
To: oak-dev@jackrabbit.apache.org
Subject: Re: ACL on versioned node

Hi Angela,
thanks for the clarification, I thought the access control content was
versioned alongside the node. If you don't mind me asking I have another
question though (that might be a little off topic): why is required to
version a node to change its access control information if the access
control information is not part of the version information? If I restore a
node to a previous version (that had different permission settings), the
permission on the node are not restored alongside the node state, so why do
I have to version it in the first place? Am I missing something?

Marco.

On Wed, Oct 31, 2018 at 2:03 PM Angela Schreiber <an...@adobe.com.invalid>
wrote:

> Hi Marco
>
> As far as I remember the access control content is not versioned along
> with the parent node it is attached to in the default implementation. This
> is indeed due to the OPV flag set to IGNORE with the corresponding node
> type definitions. However that cannot be changed and it is somewhat
> unrelated to the issue you are seeing (i.e. the read only status of a
> checked-in node). The OPV defines what happens to an item in the subtree of
> a versionable node upon checkin i.e. the creation of a new version and
> which imformation also makes it in which form to the version storage
> (IGNORE: not copied to version storage at all). It also has an impact on
> restore. You will find all the details in the specification.
>
> Kind regards
> Angela
> ________________________________________
> From: Marco Piovesana <pi...@esteco.com>
> Sent: Wednesday, October 31, 2018 9:53 AM
> To: oak-dev@jackrabbit.apache.org
> Subject: Re: ACL on versioned node
>
> Sure,
> I'll add a JIRA for it with the test case. One more question, if I want to
> separate the versioning of the node from the permission policy on it, can I
> set the OPV to ignore for the relative rep:policy node? Or that just
> doesn't work?
>
> Marco
>
> On Wed, Oct 31, 2018 at 8:52 AM Angela Schreiber <anchela@adobe.com.invalid
> >
> wrote:
>
> > Hi Marco
> >
> > Upon checkin of a versionable node (and it's non-versionable subtree)
> > becomes read-only. I think the first behavior is a bug.  Changing
> > permissions of a checked-in node should not be possible. The reason why
> you
> > are seeing it in the second case is due to the fact that a mixin is
> > automatically added to the checked-in node. But also the modification of
> > access control content in the subtree should trigger the exception (which
> > it doesn't apparently)
> >
> > Here a quote from the specification:
> > The node N and its connected non-versionable subtree become read-only.
> N's
> > connected non-versionable subtree is the set of non-versionable
> descendant
> > nodes reachable from N through child links without encountering any
> > versionable nodes. In other words, the read-only status flows down from
> the
> > checked-in node along every child link until either a versionable node is
> > encountered or an item with no children is encountered.
> >
> > Since the policy node and the access controlled content stored therein is
> > not versionable the checkin status of it's versionable parent (or
> ancestor
> > for that matter) should be enforced.
> >
> > May I ask you to create a JIRA ticket for that?
> > Thanks
> > Angela
> >
> > ________________________________________
> > From: Marco Piovesana <pi...@esteco.com>
> > Sent: Tuesday, October 30, 2018 7:05 PM
> > To: oak-dev@jackrabbit.apache.org
> > Subject: ACL on versioned node
> >
> > Hi all,
> > I'm using Oak 1.8.1 and I don't think I fully understand how permissions
> > are handled in versioned nodes.
> >
> > If I create the first version of a node *after* adding an ACE to it,
> then I
> > can add or remove other ACE without having to checkout the node.
> >
> > If I create the first version of the node *before* adding the first ACE,
> > then I get the error (*OakVersion0001: Cannot change property
> > jcr:mixinTypes on checked in node*) whenever i try to modify the node
> > permissions without checking it out first.
> >
> > what is the expected behavior? Checkout should be required or not to
> modify
> > the user's permission on the node?
> >
> > Marco.
>