systemd.services.<name>.path appends /bin to each entry, so the
literal '/run/wrappers/bin' here was being expanded to
'/run/wrappers/bin/bin' inside the unit's PATH — a path that
doesn't exist. 'which sudo' then fell back to
'/run/current-system/sw/bin/sudo' (the non-setuid nix-store binary)
and refused with 'must be owned by uid 0 and have the setuid bit
set' on every agent, despite hyperhive.user.passwordlessSudo = true.
Verified on this container post-rebuild:
PATH includes /run/wrappers/bin/bin (non-existent)
/run/wrappers/bin/sudo exists with mode r-s--x--x (real setuid)
but `sudo` resolves to /run/current-system/sw/bin/sudo and fails.
Fix: drop the trailing /bin from both entries. systemd appends it.
The /run/current-system/sw entry was already correctly
expanding to /run/current-system/sw/bin (because of the same
auto-append), which is why everything else on PATH worked despite
the broken wrappers entry — only sudo (the one binary that needs
the wrapper dir) was affected.
b714ba15c2