I’m sure it is a setup issue on my part, but am trying to block access to creation of a list member.
Here is my id:
MDS1-ESUA:~$ confd_cli -C --user=fred2 --groups=standard
fred2 connected from 10.41.0.245 using ssh on MDS1-ESUA
MDS1-ESUA# id
user = fred2(1001), gid=1001, groups=standard, gids=1001
There is an object of the form:
olt ont config [aid] The ont config list which is indexed by an index named aid.
The actual list has tons of attributes, so I omitted here for brevity.
where the named ont configuration is stored.
I want to restrict the creation of the members of this list from all users so they are forced to use the action:
olt ont create … and are blocked from creating via the normal create list entry mechanism.
The user would be allowed to edit attributes of already created entries.
The user in question is in the group standard as above.
I have these rules pretty much at the top of the list of nacm rules.
A user in the group standard (user) is allowed to create list entries and is not blocked.
I also have tried to block write access for standard users from certain list attributes (for all list entries) but as I understand it that is not supported?
global-deny-rules
maintenance
readonly
standard
admin
<rule>
<name>ont-creation-action-only</name>
<module-name>tolt</module-name>
<path>/tolt/ont/*</path>
<access-operations>create</access-operations>
<action>deny</action>
</rule>
<rule>
<name>ont-deny-ser-num-edit</name>
<module-name>tolt</module-name>
<path>/tolt/ont/config[aid]/ont/serial-num</path>
<access-operations>create update</access-operations>
<action>deny</action>
</rule>
<rule>
<name>ont-deny-ont-id-edit</name>
<module-name>tolt</module-name>
<path>/tolt/ont/config/aid/ont/ont-id</path>
<access-operations>update</access-operations>
<action>deny</action>
</rule>
<rule>
<name>ont-registration-id-hide</name>
<module-name>tolt</module-name>
<path>/tolt/ont/config/aid/ont/ont-id</path>
<access-operations>read update</access-operations>
<action>deny</action>
</rule>
</rule-list>
Any guidance is greatly appreciated.
Hi Les,
I was able to make a simple example work so I’ll show you that but also give you a debugging hint. First, I got it to work for a list:
<config xmlns="http://tail-f.com/ns/config/1.0">
<l xmlns="urn:simple">
<name>index1</name>
</l>
<l xmlns="urn:simple">
<name>index4</name>
<number>6</number>
</l>
</config>
with a rule:
rule-list aaa-no-recreate-rules {
group [ test ];
rule no-create-l {
module-name simple;
path /l;
access-operations create;
action deny;
log-if-permit;
}
}
With this configuration, I’m able to edit an existing list entry (index4 number 6
was index 4 number 4
but I can’t add a new one:
fred2@linux% set l index4 number 6
[ok][2025-04-03 19:18:20]
[edit]
fred2@linux% commit
Commit complete.
[ok][2025-04-03 19:18:22]
[edit]
fred2@linux% set l index-new
Aborted: failed to create path - access denied
[error][2025-04-03 19:20:07]
[edit]
The debugging hint that are useful are the log-if-permit
in the rule (requires <developerLogLevel>trace</developerLogLevel>
). This lets you see what is happening, and what rules are actually affecting the behavior, in the devel.log, e.g.:
==> log/devel.log <==
<DEBUG> 3-Apr-2025::19:36:20.686 linux confd[13933][<0.1335.0>]: devel-aaa User: fred2[test] rejected data access path /simple:l op create due to rule "aaa-no-recreate-rules/no-create-l"
I hope this helps,
Scott
I get an error if I use the log-if-permit directive. I assume this is because I need to somehow be using the extension for the aaa.
Here is the top of my aaa rules file.
Also I have the developer log level set to trace but it doesn’t output anything about the rules being processed in the confd devel log.
Often this happens because it is hitting a rule that doesn’t have log-if-permit set. See if you can determine if there is a rule that is allowing everything before it even hits your new rules.
What about this? log-if-permit is not seen as a valid attribute? How do I get the extensions to work?
Also one other question. If the user is the root user, with gid(0) will it ignore all nacm rules? I believe that is a part of my issue.
I haven’t seen an error on using log-if-permit. Did you attach the top of your rules file?
Also, NACM rules are based on the groups the user is assigned to in
admin@linux> show configuration nacm
write-default permit;
groups {
group admin {
user-name [ admin private ];
}
group oper {
user-name [ oper public ];
}
}
and then groups are configured for each rule in the rule-list. So, a root user in your system doesn’t automatically ignore all rules. It may get into a bunch of groups. You can see that in the audit log. but it will still follow the NACM rules.
This is the top of my aaa config file. My understanding of log-if-permit is that it is an extension of ietf nacm made by tailf. This is the top of my file. Just want to make sure I’m doing it right to get that extension.
I have groups for each “category” of users. They are all associated with specific groups. When I do an id, I see the correct group.