Page MenuHomeVyOS Platform
Create Task
Maniphest T7808

'monitor command' feature no longer works after T7745
Closed, DuplicatePublicBUG
Actions

Description

I recently noticed that in current rolling releases, the monitor command feature no longer works without the user being applied to an operator group. I walked through the different op-mode commands, and this appears to be the only command impacted. I didn't do an exhaustive crawl though.

The error that is shown is this:

Internal error: User vyos is not assigned to any operator group

Additionally, when attempting to execute an op-mode command from the shell, the same error is shown. This used to work, but I'm not sure if that was a feature, or just an artifact of how op-mode commands worked.

root@vyos:/home/vyos# show interfaces
Internal error: User vyos is not assigned to any operator group

Details

Version
1.5
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Related Objects
Search...

Event Timeline

L0crian created this task.Sep 11 2025, 6:42 PM
L0crian updated the task description. (Show Details)Sep 11 2025, 6:48 PM
pasik subscribed.Sep 11 2025, 7:41 PM
Unknown Object (User) assigned this task to dmbaturin.Sep 16 2025, 11:15 AM
Unknown Object (User) triaged this task as High priority.
jestabro added a subtask: T7901: Operational mode commands cannot be executed when the effective UID is already zero.Oct 2 2025, 5:02 PM
Viacheslav subscribed.EditedMon, Dec 1, 2:05 PM

Not sure if it is the correct fix but something with this logic https://github.com/vyos/vyos-utils/blob/dbecbd0c4f25f8b8d7055e5ed3ffc8e5be59b1f0/src/vyos_op_run.ml#L297

vyos_bld@f6cdb13e6535:/vyos/work/tmp/vyos-utils$ git diff
diff --git a/src/vyos_op_run.ml b/src/vyos_op_run.ml
index c7e38a7..f330935 100644
--- a/src/vyos_op_run.ml
+++ b/src/vyos_op_run.ml
@@ -294,7 +294,10 @@ let check_command_permissions perms cmd =
   let groups = Yojson.Safe.Util.path ["users"; username] perms in
   match groups with
   | None | Some (`List []) ->
-    Printf.ksprintf internal_error "User %s is not assigned to any operator group" username
+    (* Printf.ksprintf internal_error "User %s is not assigned to any operator group" username *)
+    (* Automatically assign user to 'default' group when not explicitly listed *)
+    let group_list = ["default"] in
+    aux perms group_list cmd
   | Some gs ->
     let group_list =
       (try

Operators:

root@r14:/home/vyos# cat /etc/vyos/operators.json | jq
{
  "users": {
    "foo": [
      "operator"
    ]
  },
  "groups": {
    "default": {
      "command_policy": {
        "allow": [
          [
            "*"
          ]
        ]
      }
    },
    "operator": {
      "command_policy": {
        "allow": [
          [
            "show",
            "*"
          ]
        ]
      }
    }
  }
}
root@r14:/home/vyos#
dmbaturin closed this task as a duplicate of T7901: Operational mode commands cannot be executed when the effective UID is already zero.Thu, Dec 4, 2:31 PM
dmbaturin added a comment.Thu, Dec 4, 2:33 PM

This is a different maniphestation of the same mistake I made in is_admin — not checking if the effective UID is already zero. User vyos is a red herring because it's the actual user name but what actually matters is the effective UID instead.