Where should privileged helper scripts live on an immutable-root distro?

[vladimirrott]

SysKnife's daemon runs twelve privileged helper scripts. Each exists to replace a wider sudo grant with a narrow one: grub-kargs-edit replaced unconstrained cp, python3 and update-grub grants, and sysctl-edit exists so no bare sysctl grant is needed, since sysctl -p <file> would let the daemon load an attacker's file.

The grants name one absolute path each:

sysknife ALL=(root) NOPASSWD: /usr/lib/sysknife/grub-kargs-edit *

That path is written down in three places that all have to agree: twelve const strings in the daemon, twelve NOPASSWD grants, and twelve Makefile install lines.

On Fedora Atomic, /usr/lib is read-only, so make install cannot put them there. It has never worked; see #301.

Why each obvious answer costs something

Move them to /usr/local/lib/sysknife. Works everywhere, no new packaging. /usr/local is /var/usrlocal on ostree, root-owned, so the sysknife user still cannot plant a script there, and the daemon binary already installs there on ostree anyway. The cost is migrating the layout of the primary platform, Ubuntu, to accommodate the deprioritized one, across twenty-four sites, with a window where a new binary against an old sudoers file loses every helper-backed action.

Move them to /etc/sysknife/helpers. Writable on ostree, root-only, and /etc already holds executables on Debian systems (/etc/cron.daily, /etc/network/if-up.d). Same migration cost, plus executables in a directory the FHS reserves for configuration.

Ship an RPM and layer it with rpm-ostree. Puts them at /usr/lib/sysknife inside the ostree commit, immutable, exactly where the grants and constants already point, and Ubuntu is untouched. The cost is a spec file, a build job and a second release artifact.

What I would like to hear

If you have shipped a Rust daemon with root-executed helper scripts onto Silverblue, Kinoite, or any image-based distro, what did you do with them, and what went wrong with it a year later?

Two specific things I do not know:

• Whether a layered RPM is a reasonable ask of an operator who arrived via npx sysknife-setup, or whether it splits the install story badly enough that the path migration is the lesser evil.
• Whether anyone has a fourth option. A configurable helper directory is out, because pointing it at somewhere writable turns a NOPASSWD wildcard into arbitrary root execution, but I would rather be shown a better shape than defend that list.

Absent better input I will do the RPM, because it leaves the primary platform alone and works with the platform rather than around it. I would rather change my mind now than after the spec file exists.