users list, hidden password leaf

[dwdengwei]

version：2.1.46

1、edit-config

2、get ， The password leaf should be hidden expect result is

3、 but it returns all users' passwords

How to achieve the result of step 2? Is there anything not configured correctly? Thank you!!

[michalvasko]

Why exactly should password be hidden? Is there a reason other than the specification saying it somewhere?

[jktjkt]

In NETCONF, this is implemented via NACM which is fully supported by netopeer2. Your YANG models and data have to set up the appropriate access rules so that access to the password leaf is denied by default.

This is an example on how this is implemented in our system, which is not based on O-RAN. The models has the following bits, not the nacm: statements:

  container authentication {
    list users {
      config false;
      key 'name';
      description "All user accounts which are configured in the Linux system";

      leaf name {
        type username-type;
      }

      leaf password {
        nacm:default-deny-all;
        type password-type;
      }

      // ...
  }

...and then you need to set up the actual NACM configuration so that people can access their own account:

{
  "ietf-netconf-acm:nacm": {
    "rule-list": [
      {
        "name": "Authentication details of current user",
        "group": [
          "*"
        ],
        "rule": [
          {
            "name": "Allow reading and executing actions in the context of the current user",
            "access-operations": "exec read",
            "module-name": "your-module-name",
            "action": "permit",
            "path": "/your-module-name:authentication/users[name=$USER]"
          }
        ]
      }
    ]
  }
}

Also note that operations triggered by the NACM administrator bypass these checks. If your requirements were something crude like "please store the password in cleartext in the YANG DB, but then do not actually show them to anyone", then NACM won't help you. What you can do is to intercept the incoming request for changing the password where the password is provided as cleartext, and have the password rewritten to, e.g., a secure hash. You can do this within your sysrepo callbacks which implement the actual backend operations.