Subject: [Netconf] Permission inheritance in NACM

From: Pavel Špírek <[email-masked]>
Date: Thu, 18 Feb 2016 09:53:48 +0100

Hello,
I am currently working on implementation of NACM for RESTCONF and I 
would like to ask if there is some kind of permission inheritance in 
Netconf Access Control Module (RFC 6536). The procedure of access 
validation to specific data node is described in paragraph 3.4.5. of RFC 
6536. But it's not quite clear if I should also consider rules 
controlling access to parent data nodes.

I checked implementation of NACM in libnetconf (nacm.c:1236), and it 
also doesn't look like that parent nodes are processed there (or I am 
missing something)...

Thanks,
Pavel Spirek

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Feb 2016 09:15:21 -0800

Hi,

NACM has not been updated to support RESTCONF.
Eventually the NETCONF WG will produce an update and WG consensus will
determine the answer to your question.

My guess is that ancestor nodes of the target resource data node are treated
the same as NETCONF where the operation="none".  (i.e., all ancestors need
to exist).

Andy

On Thu, Feb 18, 2016 at 12:53 AM, Pavel Špírek <[email-masked]> wrote:

> Hello,
> I am currently working on implementation of NACM for RESTCONF and I would
> like to ask if there is some kind of permission inheritance in Netconf
> Access Control Module (RFC 6536). The procedure of access validation to
> specific data node is described in paragraph 3.4.5. of RFC 6536. But it's
> not quite clear if I should also consider rules controlling access to
> parent data nodes.
>
> I checked implementation of NACM in libnetconf (nacm.c:1236), and it also
> doesn't look like that parent nodes are processed there (or I am missing
> something)...
>
> Thanks,
> Pavel Spirek
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 18 Feb 2016 19:10:04 +0100

> On 18 Feb 2016, at 18:15, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 

How does it work in NETCONF? Is it possible for a client to have read access to a leaf if it doesn't have read access to an ancestor container?

In terms of RFC 6536, does "path" match mean an exact match or prefix match?

Lada 

> I am currently working on implementation of NACM for RESTCONF and I would like to ask if there is some kind of permission inheritance in Netconf Access Control Module (RFC 6536). The procedure of access validation to specific data node is described in paragraph 3.4.5. of RFC 6536. But it's not quite clear if I should also consider rules controlling access to parent data nodes.
> 
> I checked implementation of NACM in libnetconf (nacm.c:1236), and it also doesn't look like that parent nodes are processed there (or I am missing something)...
> 
> Thanks,
> Pavel Spirek
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Feb 2016 10:28:53 -0800

On Thu, Feb 18, 2016 at 10:10 AM, Ladislav Lhotka <[email-masked]> wrote:

> How does it work in NETCONF? Is it possible for a client to have read
> access to a leaf if it doesn't have read access to an ancestor container?
>
>
It is not possible in NETCONF to retrieve data from within a subtree.
Only top-level subtrees can be returned.  I would expect RESTCONF to
enforce GET access
from the root to the target node.

The operation="none" applies to write operations.  If the target is /X/Y
then /X must exist,
but no write access is checked for /X.

Note that NACM w/RESTCONF does not work well with HTTP caching.
The ETag and timestamp are associated with the data node, not each client's
view of the data node.  If the NACM rules change that affect node /X,
this will change the resource representation received by specific clients.
However the ETag and timestamp do not change.  If the client uses
If-None-Match
then a 304 Not Modified is returned -- even though NACM changed the
representation for a particular client (add and/or remove nodes from view)

exact match

Andy

> 6536. But it's not quite clear if I should also consider rules controlling
> access to parent data nodes.
> >