Subject: [netconf] ietf-netconf-acm extensions

From: Michal Vaško <[email-masked]>
Date: Thu, 18 Jul 2019 08:51:56 +0200

Hi,

I would like to ask for some clarification of NACM extensions meaning when performing an <edit-config> because my current understanding is most likely wrong. I will illustrate on an example using ietf-netconf-acm@2018-02-14 data.

running configuration:

<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
  <enable-nacm>true</enable-nacm>
  <write-default>true</write-default>
</nacm>

An arbitrary user (not root, so not the recovery session) sends this <edit-config> config:

<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
  <enable-nacm>false</enable-nacm>
</nacm>

Now, NACM rules are being applied:
1) On the "nacm" container no access is required (default "merge" operation on an already existing node [1] 5th paragraph)
2) On the "enable-nacm" write access should be required (decided at 12. in [2])

So the access is granted and NACM is now disabled. I understand this is mostly due to "write-default" being "permit" but what about the "default-deny-all" extension instance on the top-level "nacm" container? I think it was meant to deny any access to the NACM data for every user without explicit NACM rule. Effectively, it does absolutely nothing because the top-level container can always exist (I guess it depends on the implementation) so for every <edit-config> no access will be required for this node. Am I missing something?

Regards,
Michal

[1] https://tools.ietf.org/html/rfc8341#page-17
[2] https://tools.ietf.org/html/rfc8341#section-3.4.5

---

From: Andy Bierman <[email-masked]>
Date: Sun, 21 Jul 2019 13:07:20 -0700

On Wed, Jul 17, 2019 at 11:52 PM Michal Vaško <[email-masked]> wrote:

> Hi,
>
> I would like to ask for some clarification of NACM extensions meaning when
> performing an <edit-config> because my current understanding is most likely
> wrong. I will illustrate on an example using ietf-netconf-acm@2018-02-14
> data.
>
> running configuration:
>
> 1) On the "nacm" container no access is required (default "merge"
> operation on an already existing node [1] 5th paragraph)
> So the access is granted and NACM is now disabled. I understand this is
> mostly due to "write-default" being "permit" but what about the
> "default-deny-all" extension instance on the top-level "nacm" container? I
> think it was meant to deny any access to the NACM data for every user
> without explicit NACM rule. Effectively, it does absolutely nothing because
> the top-level container can always exist (I guess it depends on the
> implementation) so for every <edit-config> no access will be required for
> this node. Am I missing something?
>
>
The NACM extensions apply to the entire subtree, so access to to
enable-nacm leaf is
subject to the default-deny-all extension.

> Michal

Andy

> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>