Files
mesh-catalog/modules/sudo
jschoubben 125929dbc4
mesh/delivery ready: it is merged on the Approve
mesh/check failed (12): unit: ..a consumer faile…; and 11 more | 125929dbc459 on fd4931a75261 | judged by the candidate's mesh-build-go at 9fe836e155bd
mesh/delivery-group group feat/registry-milestone rejected: composed together: the checker's verdict at the members' heads (3a038b9f8b4d): unit: ..a consumer f…
Pin mesh-sdk 05b3e2e1b94f and mesh-contracts ae5266e77639, the group's final heads, in every Go module (issue 1966)
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
2026-11-04 18:46:38 +01:00
..

sudo

Privilege escalation as a module (novox/hq to-be 42 Phase 1, research 027).

What it owns

  • The sudo package.
  • /etc/sudoers.d/10-mesh-operator, root's, mode 0440, written whole: <operator account> ALL=(ALL:ALL) NOPASSWD: ALL, and Defaults use_pty: a command run through sudo gets a terminal of its own, so an agent the operator starts as the agent account (hq ADR 0266) cannot push keystrokes into the operator's shell. The rule names the operator account and nobody else: the agent account has no sudo.

That one line is what the mesh's acting tools assume: the packet filter, the service manager and the intrusion prevention tools act through sudo -n as the operator account (to-be 38 WP4). Before this module, nothing declared it. Each machine said it in its own line in /etc/sudoers, set by hand: a wheel group rule on two machines, the account by name on the other two.

A sudoers file that does not parse locks sudo for every account. The manifest test renders the drop-in for several account names and runs visudo -cf on each. It skips that check where visudo is not installed.

What it improves

  • The escalation is declared once, the same on every machine, and readable through its tools.
  • lab no longer declares the sudo package (novox/hq ADR 0207: a component's package belongs to one module). Lab's tools still rely on sudo, and this module provides it on every machine.

What it leaves found

  • /etc/sudoers itself: its root line, the hand-set grants (%wheel, the account by name, %sudo), and its @includedir. They are redundant beside the drop-in, and removing them is a person's act on each machine (ADR 0182). sudo_check shows each grant and the one that decides.
  • Every other file in /etc/sudoers.d.

Tools

tool answers
sudo_rules r sudo -n -l parsed: the defaults, and each rule with its run-as, tags and commands; passwordless_all
sudo_check r whether sudo -n works, every grant naming the account, its groups or ALL in the order sudo reads them, the one that decides, and whether the module's drop-in is present
sudo_drop_ins r /etc/sudoers.d with owner, mode, size, whether sudo reads each file (name, owner, mode), whether each parses, and whether the whole parses

The tools change nothing. They read root-only files through sudo -n, and a refusal is an answer, not an empty list.