**Summary**
Vyatta Core and early VyOS versions technically had support for operator-level users. The problem was that operator level users still had access to `sudo` and the access control was at the "restricted shell" level, which could be circumvented with shell escape tricks. Those tricks weren't especially obvious, but once they were discovered by a security researcher, they were proven impossible to fix in the existing code and operator level users had to be abandoned.
**Use case**
ISPs, for example, may want to grant all support engineers permissions to reset user sessions and run diagnostic commands, but restrict system upgrades only to senior engineers.
**Additional information**
Configuration mode CLI:
```
system
login
group <NAME>
# We may not need to make it a role, just an "admin" valueless node
# But may we ever want to add more roles?
role <"admin"|"operator">
permission
operational-mode
# Two possible options:
# a prefix "reset vpn ipsec"
# or a pattern, like "* vpn ipsec"
# it's a question if support for patterns is desirable or safe
command <command> (multi)
```
One way to plug a permission enforcement system into the existing codebase:
1. Strip non-admin users of sudo rights.
2. Require execution of op mode commands via a wrapper that's not written in shell.
3. Add a permission check to that wrapper.
Tag nodes present a problem, since they can have variable name, and the user can use that to inject a shell escape into the command that's passed down the line from the wrapper to an op mode script and then to a UNIX command. For the initial version, we can ban non-admin users from executing commands with completely arbitrary arguments (like traffic capture with custom filters). Eventually, we should extend the schema to support op mode tag node constraints, though.