Root add fails on SELinux-enforcing hosts: systemd may not execute /var/lib/infraternal/bin/current #417

New issue

Open

opened 2026-11-07 06:47:46 +00:00 by kayg · 0 comments

kayg commented

2026-11-07 06:47:46 +00:00

Owner

Found by J328 while proving #409 on a root host.

What happens: a root-mode Add host on an AlmaLinux 10 GenericCloud VM (SELinux Enforcing, the default on RHEL-family systems) installs the files. Then the unit never starts:

infraternal-agent.service: Unable to locate executable '/var/lib/infraternal/bin/current': Permission denied
infraternal-agent.service: Failed at step EXEC spawning /var/lib/infraternal/bin/current: Permission denied
infraternal-agent.service: Main process exited, code=exited, status=203/EXEC

The wizard ends with "The infraternal agent did not connect. Check the host's service and network.", and setup rolls the install back.

Cause (audit log):

type=AVC msg=audit(1794033944.998:351): avc:  denied  { execute } for  pid=2525 comm="(current)" name="payload" dev="vda4" ino=8450730 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0

systemd (init_t) may not execute a file labelled var_lib_t. The binary is uploaded into /var/lib/infraternal/bin, so it gets the directory's default label (here unconfined_u, because setup writes it from an SSH session).

Scope: every root-mode add on a SELinux-enforcing host (RHEL, Alma, Rocky, Fedora, CentOS Stream). Rootless adds are not affected the same way: user units run in unconfined_t.

Environment: throwaway qemu VM on compute01 (/root/j328/vm), release build b627895ae (branch fix-remove-uninstall-409; the bug is unrelated to that branch and lives in setup's install layout). Reproduce: root-mode add to an Alma 10 cloud image with SELinux left enforcing.

Possible directions (not decided): label the binary bin_t (for example chcon -t bin_t, or restorecon with an fcontext rule) as part of setup; or install the executable under a path whose default label is executable (/usr/local/libexec/…, /opt/…) and keep only state in /var/lib.

For the #409 proof I set only that throwaway VM to permissive (setenforce 0).

Found by J328 while proving #409 on a root host. **What happens:** a root-mode Add host on an AlmaLinux 10 GenericCloud VM (SELinux **Enforcing**, the default on RHEL-family systems) installs the files. Then the unit never starts: ``` infraternal-agent.service: Unable to locate executable '/var/lib/infraternal/bin/current': Permission denied infraternal-agent.service: Failed at step EXEC spawning /var/lib/infraternal/bin/current: Permission denied infraternal-agent.service: Main process exited, code=exited, status=203/EXEC ``` The wizard ends with "The infraternal agent did not connect. Check the host's service and network.", and setup rolls the install back. **Cause (audit log):** ``` type=AVC msg=audit(1794033944.998:351): avc: denied { execute } for pid=2525 comm="(current)" name="payload" dev="vda4" ino=8450730 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0 ``` systemd (`init_t`) may not execute a file labelled `var_lib_t`. The binary is uploaded into `/var/lib/infraternal/bin`, so it gets the directory's default label (here `unconfined_u`, because setup writes it from an SSH session). **Scope:** every root-mode add on a SELinux-enforcing host (RHEL, Alma, Rocky, Fedora, CentOS Stream). Rootless adds are not affected the same way: user units run in `unconfined_t`. **Environment:** throwaway qemu VM on compute01 (`/root/j328/vm`), release build `b627895ae` (branch `fix-remove-uninstall-409`; the bug is unrelated to that branch and lives in setup's install layout). Reproduce: root-mode add to an Alma 10 cloud image with SELinux left enforcing. **Possible directions (not decided):** label the binary `bin_t` (for example `chcon -t bin_t`, or `restorecon` with an fcontext rule) as part of setup; or install the executable under a path whose default label is executable (`/usr/local/libexec/…`, `/opt/…`) and keep only state in `/var/lib`. For the #409 proof I set only that throwaway VM to permissive (`setenforce 0`).

kayg referenced this issue

2026-11-07 06:53:14 +00:00

Remove leaves the infraternal agent running: uninstall never starts on the host #409

kayg referenced this issue

2026-11-07 09:41:09 +00:00

Remove leaves the infraternal agent running: uninstall never starts on the host #409

kayg referenced this issue

2026-11-07 11:29:51 +00:00

Remove leaves the infraternal agent running: uninstall never starts on the host #409

kayg referenced this issue

2026-11-07 17:11:03 +00:00

Remove leaves the infraternal agent running: uninstall never starts on the host #409