readme

CHANGELOG.md

@@ -72,6 +72,7 @@
     example backend_main() and others if you need details.
 
 ### Minor changes
+* Renamed test/test_auth*.sh tests to test/test_nacm*.sh
 * YANG keywords "action" and "belongs-to" implemented by syntactically by parser (but not proper semantics).
 * clixon-config YAML file has new revision: 2018-10-21.
 * Allow new lines in CLI prompts 

README.md

@@ -16,7 +16,8 @@ support.
   * [Netconf](#netconf)
   * [Restconf](#restconf)
   * [Datastore](datastore/README.md)
-  * [Authentication and Authorization](#auth)
+  * [Authentication](#auth)
+  * [NACM Access control](#nacm)
   * [Example](example/)
   * [Changelog](CHANGELOG.md)
   * [Runtime](#runtime)
@@ -175,10 +176,38 @@ The clients send the ID of the user using a "username" attribute with
 the RPC calls to the backend. Note that the backend trusts the clients
 so the clients can in principle fake a username.
 
-There is an ongoing effort to implement authorization for Clixon
+NACM
-according to [RFC8341(NACM)](https://tools.ietf.org/html/rfc8341), at
+====
-least a subset of the functionality. See more information here:
+Clixon includes an experimental Network Configuration Access Control Model (NACM) according to [RFC8341(NACM)](https://tools.ietf.org/html/rfc8341). It has limited functionality.
-[NACM](README_NACM.md).
+
+The support is as follows:
+
+* There is a yang config variable `CLICON_NACM_MODE` to set whether NACM is disabled, uses internal(embedded) NACM configuration, or external configuration. (See yang/clixon-config.yang)
+* If the mode is internal, NACM configurations is expected to be in the regular configuration, managed by regular candidate/runing/commit procedures. This mode may have some problems with bootstrapping.
+* If the mode is `external`, the `CLICON_NACM_FILE` yang config variable contains the name of a separate configuration file containing the NACM configurations. After changes in this file, the backend needs to be restarted.
+* The [example](example/README.md) contains a http basic auth and a NACM backend callback for mandatory state variables.
+* There are two [tests](test/README.md) using internal and external NACM config
+* The backend provides a limited NACM support (when enabled) described below
+
+NACM is implemented in the backend and a single access check is made
+in `from_client_msg()` when an internal netconf RPC has
+just been received and decoded. The code is in `nacm_access()`.
+
+The functionality is as follows:
+* Notification is not supported
+* Groups are supported
+* Rule-lists are supported
+* Rules are supported as follows
+  * module-name: Only '*' supported
+  * access-operations: only '*' and 'exec' supported
+  * rpc-name: fully supported (eg edit-config/get-config, etc)
+  * action: fully supported (permit/deny)
+
+The tests outlines an example of three groups (taken from the RFC): admin, limited and guest:
+* admin: Full access
+* limited: Read access (get and get-config)
+* guest: No access
+
 
 Runtime
 =======

README_NACM.md

@@ -1,34 +0,0 @@
-# NACM
-
-Clixon includes an experimental NACM implementation according to [RFC8341(NACM)](https://tools.ietf.org/html/rfc8341).
-
-The support is as follows:
-
-* There is a yang config variable `CLICON_NACM_MODE` to set whether NACM is disabled, uses internal(embedded) NACM configuration, or external configuration. (See yang/clixon-config.yang)
-* If the mode is internal, NACM configurations is expected to be in the regular configuration, managed by regular candidate/runing/commit procedures. This mode may have some problems with bootstrapping.
-* If the mode is `external`, the `CLICON_NACM_FILE` yang config variable contains the name of a separate configuration file containing the NACM configurations. After changes in this file, the backend needs to be restarted.
-* The [example](example/README.md) contains a http basic auth and a NACM backend callback for mandatory state variables.
-* There are two [tests](test/README.md) using internal and external NACM config
-* The backend provides a limited NACM support (when enabled) described below
-
-NACM functionality
-==================
-
-NACM is implemented in the backend and a single access check is made
-in from_client_msg() when an internal netconf RPC has
-just been received and decoded. The code is in nacm_access().
-
-The functionality is as follows:
-* Notification is not supported
-* Groups are supported
-* Rule-lists are supported
-* Rules are supported as follows
-  * module-name: Only '*' supported
-  * access-operations: only '*' and 'exec' supported
-  * rpc-name: fully supported (eg edit-config/get-config, etc)
-  * action: fully supported (permit/deny)
-
-The tests outlines an example of three groups (taken from the RFC): admin, limited and guest:
-* admin: Full access
-* limited: Read access (get and get-config)
-* guest: No access

test/README.md

@@ -4,8 +4,8 @@ This directory contains testing code for clixon and the example
 routing application. Assumes setup of http daemon as describe under apps/restonf
 - clixon    A top-level script clones clixon in /tmp and starts all.sh. You can copy this file (review it first) and place as cron script
 - all.sh    Run through all tests named 'test*.sh' in this directory. Therefore, if you place a test in this directory matching 'test*.sh' it will be run automatically. 
-- test_auth.sh      Auth tests using internal NACM
+- test_nacm.sh      Auth tests using internal NACM
-- test_auth_ext.sh  Auth tests using external NACM
+- test_nacm_ext.sh  Auth tests using external NACM (separate file)
 - test_cli.sh       CLI tests
 - test_netconf.sh   Netconf tests
 - test_restconf.sh  Restconf tests

test/test_nacm.sh

@@ -139,7 +139,7 @@ new "kill old restconf daemon"
 sudo pkill -u www-data clixon_restconf
 sleep 1
 new "start restconf daemon (-a is enable basic authentication)"
-sudo start-stop-daemon -S -q -o -b -x /www-data/clixon_restconf -d /www-data -c www-data -- -f $cfg -y $fyang -- -a 
+sudo su -c "/www-data/clixon_restconf -f $cfg -y $fyang -- -a" -s /bin/sh www-data &
 
 sleep 1