NACM authorization results in different restriction due to difference in cli operation

YANG
1

Hi,

I have added a rule in my aaa-config.xml where for all groups, I deny update and delete operations for the contents of a list.

The corresponding yang file looks like this:
container Table A {

    leaf A {}
    leaf B {}
    container Table {
      list rec {
         key id
         leaf id{}
         leaf desc {}
         leaf type {}
         leaf sub-type
      }
    } 
}

Then I try to create a new record for the list using cli and direct rpc netconf message.

What I have observed is that if I use in confd_cli, load merge <conf.xml> then the operation sent to confd is “created” for the rec and then in the logs I see that the values are set for each parameter (desc,type,sub-type).

But if I try to use set in confd_cli then in confd the operation sent is " op update" for each parameter apart from the key and due to the rule I have added it fails.

Can you please explain to me how I can create a new record using cli, without providing the configuration in xml format?

I have also used an rpc netconf message with <default-operation>merge</default-operation> which succeeds as it also sends create instead of update.

Thank you in advance for your support,
Dimitra

2

Hi,

If your rule look something like below, your rule will work:

    ...
    <rule-list>
      <name>any-group</name>
      <group>*</group>
      <rule>
        <name>test-rule</name>
        <path>/Table/rec</path>
        <access-operations>update delete</access-operations>
        <action>deny</action>
      </rule>
...

Quick demo:

$ confd_cli -u oper -g oper
oper connected from 127.0.0.1
> config
Entering configuration mode private
% show Table 
No entries found.
% set Table rec test desc testdesc
% commit
Commit complete.
% set Table rec test desc tryandedit
Error: access denied
% delete Table rec test             
Error: access denied
% delete Table rec test desc 
Error: access denied
% show Table
rec test {
    desc testdesc;
}
% set Table rec test2 desc testdescr2
% commit
% show Table
rec test {
    desc testdesc;
}
rec test2 {
    desc testdescr2;
}
3

Do you have default values for your leafs?
For example:

leaf desc { type string; default "my default description";}

In that case, setting the desc node to something will be considered an update and the rule will trigger.

4

Hi,

Yes the leafs inside the list have default values.
So I guess that is the reason why it sends opearation update.

But why this is not the case if I add the configuration via load merge ?

With merge operation it sets the values and I get no access denied.

PS: This is exactly how I have implemented the rule.

5

I suggest you report this behaviour through your Tail-f support account.