Delete restriction for configuration mode

Hi,

I have done a yang model for configuration of some datum.

In this implementation, I need to restrict delete option of this yang model.
How can I implement??

thanks in advance
Banumoorthy

Banumoorthy,
The best way I know to remove the delete option is to set up the access control rules to not allow deletion. You can specify a rule down to a specific leaf, and also the operations that are permitted, where the operations are create, read, update, delete and execute. You can look at chapter 14 on the AAA infrastructure, particularly the section on authorization.

Hi Greg Olin,

Thank you for your reply…

I have referred the section, which you have mentioned(chapter 14 on the AAA infrastructure, authorization section)

Actually I need to restrict delete option of configuration commands…

In the user guide, many rule-lists are mentioned. Like cmdrule, datarule…

For Eg:

container employee {
leaf name {
type string;
}
leaf empno {
type int32;
}
leaf grade {
type string;
}
}

My requirement is to allow the user only to configure the employee db. deleting employee details should throw error…

So, I have done a rule like below,
<config xmlns="http://tail-f.com/ns/config/1.0"> <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"> <rule-list> <name>cli-level-1</name> <group>level-1</group> <cmdrule xmlns="urn:example:params:xml:ns:yang:employee-db"> <name>delete-employee</name> <context>cli</context> <command>delete employee</command> <access-operations>delete</access-operations> <action>deny</action> </cmdrule> </rule-list> </nacm> </config>

But restriction is not happening…
I might be done wrong in implementing. But I cannot get mistake.
Is the implementation is right? or any modification required?

Thanks in advance,
Banumoorthy M

Hi Banumoorthy,

Data rules should be used instead and the rule-list should look like the following:

<rule-list>
  <name>employee-db</name>
  <group>*</group>
  <rule>
    <name>employee-db-access</name>
    <module-name>employee-db</module-name>
    <access-operations>create read update</access-operations>
    <action>permit</action>
  </rule>
  <rule>
    <name>employee-db-restriction</name>
    <module-name>employee-db</module-name>
    <access-operations>delete</access-operations>
    <action>deny</action>
  </rule>
</rule-list>

Regards,

Wai

Hi Wai,

Still I am not able to restrict delete…My rule lists are like below…
First I implemented for restricting name only…

rule-list employee-db { group [ * ]; rule employee-db-access { module-name *; path /employee/Name; access-operations create,update,read; action permit; context *; } rule employee-db-restriction { module-name *; path /employee/Name; access-operations delete; action deny; } }
Is there anything I need to do with username and groups.?
My id command output is
`bmurali@rtxplgn09> id
user = bmurali(1254155515), gid=50063, groups=, gids=50063
[ok][2015-12-17 03:01:10]

Please suggest…

Thanks in advance,
Banumoorthy M`

Following are the complete steps for creating such a project:

$ ls
Makefile		confd.conf
aaa_init.xml		employee-db.yang
$ diff aaa_init.xml $CONFD_DIR/var/confd/cdb/aaa_init.xml
97,112d96
<       <name>employee-db</name>
<       <group>*</group>
<       <rule>
<         <name>employee-db-access</name>
<         <module-name>employee-db</module-name>
<         <access-operations>create read update</access-operations>
<         <action>permit</action>
<       </rule>
<       <rule>
<         <name>employee-db-restriction</name>
<         <module-name>employee-db</module-name>
<         <access-operations>delete</access-operations>
<         <action>deny</action>
<       </rule>
<     </rule-list>
<     <rule-list>

$ make all start
$CONFD_DIR/bin/confdc -c employee-db.yang
mkdir -p ./confd-cdb 2>/dev/null || true
cp ./aaa_init.xml ./confd-cdb
ln -s $CONFD_DIR/etc/confd/ssh ssh-keydir
### Killing any confd daemon
$CONFD_DIR/bin/confd --stop    || true
connection refused (stop)
$CONFD_DIR/bin/confd -c ./confd.conf  --addloadpath $CONFD_DIR/etc/confd

$ make cli
$CONFD_DIR/bin/confd_cli --user=admin --groups=admin \
		--interactive || echo Exit

admin connected from 127.0.0.1 using console on WAITAI-M-K092
admin@WAITAI-M-K092> show configuration nacm
write-default permit;
groups {
    group admin {
        user-name [ admin private ];
    }
    group oper {
        user-name [ oper public ];
    }
}
rule-list employee-db {
    group [ * ];
    rule employee-db-access {
        module-name       employee-db;
        access-operations create,read,update;
        action            permit;
    }
    rule employee-db-restriction {
        module-name       employee-db;
        access-operations delete;
        action            deny;
    }
}
rule-list admin {
    group [ admin ];
    rule any-access {
        action permit;
    }
}
rule-list any-group {
    group [ * ];
    rule tailf-aaa-authentication {
        module-name       tailf-aaa;
        path              /aaa/authentication/users/user[name='$USER'];
        access-operations read,update;
        action            permit;
    }
    rule tailf-aaa-user {
        module-name       tailf-aaa;
        path              /user[name='$USER'];
        access-operations create,read,update,delete;
        action            permit;
    }
    rule tailf-webui-user {
        module-name       tailf-webui;
        path              /webui/data-stores/user-profile[username='$USER'];
        access-operations create,read,update,delete;
        action            permit;
    }
}
[ok][2015-12-17 13:51:58]
admin@WAITAI-M-K092> configure 
Entering configuration mode private
[ok][2015-12-17 13:52:01]

[edit]
admin@WAITAI-M-K092% set employee name test
[ok][2015-12-17 13:52:07]

[edit]
admin@WAITAI-M-K092% delete employee name test
Error: access denied
[error][2015-12-17 13:52:12]

[edit]
admin@WAITAI-M-K092%

Hi Wai,

It worked for me!!!

I am able to restrict the delete option based on rule-list implementation…

Thank you very much for your support.

Now I have another concern followed by the same restriction.

In YANG model,

for a container implementation, there will be only one instance maintained in cdb.

but for list implementation, there may any number of instance maintained in cdb.

So, I have restricted the delete option for container implemented yang model and allowed the delete option for list implemented yang model.

But, I need to have atleast one instance in cdb for either list or container.

For container, it is ok.

For list, I need to write condition somewhere to restrict the last instance deletion of list …

How can I implement…

Any idea…pls suggest…

Thanks and Regards,
Banumoorthy M

You can use the min-elements statement of YANG and set it to 1. This will also be enforced upon the initial startup of ConfD. You will need to have the initial factory default data in CDB to contain at least one row of data in your list by copying an XML instance document containing that row of list data and copy it to the same folder as CDB.

Thank you very much Wai for your full support…

Hi Waitai,
Is it possible to disable delete of certain element in the list?
In above example, let say, there are three employees, e1, e2, e3. We do not want to delete employee e2 ever, it is like default employee, whose record will always be present in cdb.
If you execute a command like, no employee, it should delete all employees except e2. Is it possible?

Thanks,
Manish

The example used in the original posting was just a plain container with 3 leaf elements. I am assuming that you are asking about a hypothetical question if the container is being turned into a list instead and how would you prevent a particular instance of the list from being deleted.

For the following example YANG list:

list employee {
    key "empno";
    leaf empno {
        type int32;
    }
    leaf name {
        type string;
    }
    leaf grade {
        type string;
    }

}

You can prevent employee #2 from being deleted by changing the rule-list named employee-db-restriction in my previous response as follows:

  <rule>
    <name>employee-db-restriction</name>
    <module-name>employee-db</module-name>
    <path>/employee[empno=2]</path>
    <access-operations>delete</access-operations>
    <action>deny</action>
  </rule>

Thank you Waitai. I’ll try it soon.

I appreciate your prompt response.

One more query, is it possible to set visibility of certain data in a way, that only the user who creates the entry can also see it. e.g let say there are two users, user1 and user2.
user1 creates employee e1, e2 and user2 creates e3, e4.

Is it possible to make sure that user1 can only access (and modify) only e1 an e2 and similarly for user2 as well.

You can create AAA rules to enforce this.

Hi Waitai … could you give an example or point to some reading material to achieve this?

Hi Waitai … could you help with a example.

Hi Manish,

You can find info and NACM examples in the ConfD UG under chapter “The AAA infrastructure” and subchapters “Authorization” —> “Authorization Examples”

If you want to change the access depending on operation you can for example do that from a subscriber application that change the authorization rules when the list entries are created.

Hi Manish,

Here’s an AAA rules example on how to allow access to an user named user1 assigned to a group also called user1 with access privileges to only instances of 1 and 2:

$ diff aaa_init_emp.xml aaa_init.xml.orig
23,30d22
<           <name>user1</name>
<           <uid>9000</uid>
<           <gid>20</gid>
<           <password>$0$user1</password>
<           <ssh_keydir>/var/confd/homes/user1/.ssh</ssh_keydir>
<           <homedir>/var/confd/homes/user1</homedir>
<         </user>
<         <user>
103,106d94
<       <group>
<         <name>user1</name>
<         <user-name>user1</user-name>
<       </group>
109,132d96
<       <name>user1</name>
<       <group>user1</group>
<       <rule>
<         <name>employee1</name>
<         <module-name>employee-db</module-name>
<         <path>/employee[empno=1]</path>
<         <access-operations>create update delete</access-operations>
<         <action>permit</action>
<       </rule>
<       <rule>
<         <name>employee2</name>
<         <module-name>employee-db</module-name>
<         <path>/employee[empno=2]</path>
<         <access-operations>create update delete</access-operations>
<         <action>permit</action>
<       </rule>
<       <rule>
<         <name>other-employees</name>
<         <module-name>employee-db</module-name>
<         <access-operations>create update delete</access-operations>
<         <action>deny</action>
<       </rule>
<     </rule-list>
<     <rule-list>

If you would like to configure this dynamically at run time, you can do it in a subscriber application as suggested by Conny in his previous response.