ward exec ansible-sync: become/sudo tasks fail under the cli-guard jail (no_new_privs) #447

New issue

Open

opened 2026-07-03 06:40:38 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-07-03 06:40:38 +00:00

Member

Summary

With the brew-prefix bug fixed (ward#546), ward exec ansible-sync local=1 now runs clean through the homebrew role (0 source builds) and fails on the first become/sudo task, because ward's jail sets no_new_privs and sudo cannot escalate inside it.

Symptom

TASK [lan-hosts : Pin LAN hostnames in /etc/hosts] *****
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Task failed:
  Premature end of stream waiting for become success.
  sudo: /etc/sudo.conf is owned by uid 65534, should be 0
  sudo: The \"no new privileges\" flag is set, which prevents sudo from running as root."}

The uid 65534 (nobody) and the no-new-privs flag are the cli-guard jail's doing (userns identity map + PR_SET_NO_NEW_PRIVS before the seccomp denylist). Any ansible task with become: true hits this.

Why it was hidden

Every prior ward exec ansible-sync failed earlier, at the homebrew source-build wall (netpbm wanting svn). Now that homebrew is bottle-clean, the play reaches the privileged tasks and this surfaces. So it is pre-existing, not new.

Options

Mark the ansible-sync verb to run outside the jail (CLIGUARD_NO_SANDBOX=1). ansible-sync does system-level convergence (writes /etc/hosts, manages systemd, etc.) that fundamentally needs privilege escalation the sandbox denies. As a bonus this also sidesteps the brew overlay entirely (real symlink -> correct prefix), so it is a viable interim unblock even before the ward#546 release lands.
Or teach the jail to permit become for this verb (keep-caps / allow setuid), which is a larger cli-guard change and weakens the sandbox.

Recommended: opt ansible-sync out of the jail. Verified locally that a jail-free run converges without the brew bug or the sudo failure.

Filed while unblocking ward exec ansible-sync on kai-server.

## Summary With the brew-prefix bug fixed (ward#546), `ward exec ansible-sync local=1` now runs clean through the homebrew role (0 source builds) and fails on the first `become`/sudo task, because ward's jail sets `no_new_privs` and sudo cannot escalate inside it. ## Symptom ``` TASK [lan-hosts : Pin LAN hostnames in /etc/hosts] ***** fatal: [localhost]: FAILED! => {"changed": false, "msg": "Task failed: Premature end of stream waiting for become success. sudo: /etc/sudo.conf is owned by uid 65534, should be 0 sudo: The \"no new privileges\" flag is set, which prevents sudo from running as root."} ``` The uid 65534 (nobody) and the no-new-privs flag are the cli-guard jail's doing (userns identity map + `PR_SET_NO_NEW_PRIVS` before the seccomp denylist). Any ansible task with `become: true` hits this. ## Why it was hidden Every prior `ward exec ansible-sync` failed earlier, at the homebrew source-build wall (netpbm wanting svn). Now that homebrew is bottle-clean, the play reaches the privileged tasks and this surfaces. So it is pre-existing, not new. ## Options - Mark the `ansible-sync` verb to run **outside the jail** (`CLIGUARD_NO_SANDBOX=1`). ansible-sync does system-level convergence (writes /etc/hosts, manages systemd, etc.) that fundamentally needs privilege escalation the sandbox denies. As a bonus this also sidesteps the brew overlay entirely (real symlink -> correct prefix), so it is a viable interim unblock even before the ward#546 release lands. - Or teach the jail to permit `become` for this verb (keep-caps / allow setuid), which is a larger cli-guard change and weakens the sandbox. Recommended: opt `ansible-sync` out of the jail. Verified locally that a jail-free run converges without the brew bug or the sudo failure. Filed while unblocking `ward exec ansible-sync` on kai-server.

coilyco-ops added the

consult

labels

2026-07-03 07:58:44 +00:00

coilyco-ops added

interactive

and removed

consult

labels

2026-07-09 21:46:19 +00:00

coilyco-ops added

and removed