Re: [i2rs] topo model use of NACM

[Andy Bierman]

On Tue, Feb 21, 2017 at 1:33 AM, Robert Wilton  wrote:

> Hi Andy,
>
> On 16/02/2017 22:36, Andy Bierman wrote:
>
>
>
> On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm <
> alexander.cl...@huawei.com> wrote:
>
>> There are actually a number of interesting implications with regards to
>> NACM.  NACM could indeed be a key to the solution if it provides sufficient
>> flexibility with regards to articulating and enforcing authorization
>> rules.  Regarding this, I have a number of questions/comments:
>>
>>
>>
>> -  If a subtree contains objects that a client does not have
>> write privileges for, will the client be prevented from locking the
>> subtree? How about the case when the client does not even have read
>> privileges?
>>
>
> locking and NACM are 2 different things.
> NETCONF has datastore (global) locks and subtree (partial) locks.
> There is no mechanism in NACM or elsewhere that constrains the values
> that a particular client can use. (NACM controls access to the rpc, with no
> control over specific input paramters).
>
>
>
>>
>> The current NACM-bis draft states in section 3.7.2 that this is not the
>> case – i.e. a client is able to lock an entire subtree, even in cases when
>> there is not a single object in that subtree that the client actually has
>> access privileges to.
>>
>>
>>
>> To me, this does not seem right.  It just invites abuse.
>>
>>
>>
>> Now, there is still the possibility to restrict access to the operation
>> overall.  But again, this means that you have to give a users an
>> all-or-nothing choice.  Too inflexible.  By the same token that partial
>> locks were supported to avoid requiring anyone who needs the ability to
>> conduct a transaction to lock down the entire server, there should be the
>> ability to restrict access to the lock and partial-lock operation by
>> targeted subtree.  However, this capability is currently missing.
>>
>
>
> NACM was designed to be simple to implement.
> Some complex features that were in VACM were intentionally left out of
> NACM.
> NETCONF locking is also intentionally simple.
>
> I would rather have NETCONF 2.0 use a mandatory implicit, optimistic
> concurrent
> locking model, rather than more band-aids on the optional explicit,
> pessimistic
> serialized locking model we have now.
>
> This is interesting.  If you have time, then at some point, please can you
> expand on this idea, perhaps on the NETCONF alias?
>
>
NETCONF does not really support concurrent transactions.
It supports serialized transactions with explicit locks.
More than that is complicated, so it's probably not going to change
any time soon.


Thanks,
> Rob
>
>

Andy
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] topo model use of NACM

[Robert Wilton]

Hi Andy,


On 16/02/2017 22:36, Andy Bierman wrote:



On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm 
> wrote:


There are actually a number of interesting implications with
regards to NACM.  NACM could indeed be a key to the solution if it
provides sufficient flexibility with regards to articulating and
enforcing authorization rules.  Regarding this, I have a number of
questions/comments:

-If a subtree contains objects that a client does not have write
privileges for, will the client be prevented from locking the
subtree? How about the case when the client does not even have
read privileges?


locking and NACM are 2 different things.
NETCONF has datastore (global) locks and subtree (partial) locks.
There is no mechanism in NACM or elsewhere that constrains the values
that a particular client can use. (NACM controls access to the rpc, 
with no

control over specific input paramters).




The current NACM-bis draft states in section 3.7.2 that this is
not the case – i.e. a client is able to lock an entire subtree,
even in cases when there is not a single object in that subtree
that the client actually has access privileges to.

To me, this does not seem right.  It just invites abuse.

Now, there is still the possibility to restrict access to the
operation overall.  But again, this means that you have to give a
users an all-or-nothing choice.  Too inflexible.  By the same
token that partial locks were supported to avoid requiring anyone
who needs the ability to conduct a transaction to lock down the
entire server, there should be the ability to restrict access to
the lock and partial-lock operation by targeted subtree.  However,
this capability is currently missing.



NACM was designed to be simple to implement.
Some complex features that were in VACM were intentionally left out of 
NACM.

NETCONF locking is also intentionally simple.

I would rather have NETCONF 2.0 use a mandatory implicit, optimistic 
concurrent
locking model, rather than more band-aids on the optional explicit, 
pessimistic

serialized locking model we have now.
This is interesting.  If you have time, then at some point, please can 
you expand on this idea, perhaps on the NETCONF alias?


Thanks,
Rob

___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs