Verify systemd lifecycle and privilege constraints #7

Closed
opened 2026-08-31 08:03:03 +00:00 by xavierk · 1 comment
Owner

Parent map: Chart Fenris’s persistent TUI monitoring redesign

Question

What systemd service architecture and Linux privilege boundary can keep Fenris collecting across reboots while allowing its on-demand TUI to inspect and explicitly change startup state? Verify system versus user service behavior, boot ordering, smartctl permissions, sudo or polkit interaction, service control, configuration ownership, data paths, and safe status reporting.

Parent map: [Chart Fenris’s persistent TUI monitoring redesign](https://git.bongbetic.com/xavierk/Fenris/issues/1) ## Question What systemd service architecture and Linux privilege boundary can keep Fenris collecting across reboots while allowing its on-demand TUI to inspect and explicitly change startup state? Verify system versus user service behavior, boot ordering, smartctl permissions, sudo or polkit interaction, service control, configuration ownership, data paths, and safe status reporting.
xavierk added this to the Wayfinder: Fenris persistent TUI monitoring redesign milestone 2026-08-31 08:03:03 +00:00
xavierk added the wayfinder:research label 2026-08-31 08:03:03 +00:00
xavierk added a new dependency 2026-08-31 08:03:19 +00:00
xavierk self-assigned this 2026-08-31 08:04:04 +00:00
Author
Owner

Resolved Verify systemd lifecycle and privilege constraints.

Answer: Use an enabled system timer plus a short-lived system oneshot collector. PID 1 should schedule collection after boot and periodically thereafter; the on-demand TUI stays unprivileged and independent. A user service would require lingering to survive logout/reboot and still cannot use User= to become root (loginctl, systemd.exec).

The collector should invoke administrator-owned smartctl directly—never embedded sudo—and limit privileged work to fixed read-only device interrogation plus state writes. Put root-owned config in /etc/fenris, durable observations in /var/lib/fenris, ephemeral coordination in /run/fenris, and diagnostics in the journal (systemd managed directories, FHS). The TUI should read a sanitized status surface and query allow-listed systemctl show properties rather than scrape human-oriented systemctl status (systemctl).

For explicit startup changes, have the TUI request enable or disable for the fixed Fenris timer and let normal polkit administrator authentication run. Keep enablement separate from current runtime state; enable/disable do not start/stop unless --now is explicitly used (systemctl). Do not grant a Fenris group the generic org.freedesktop.systemd1.manage-unit-files action: it governs unit-file operations broadly, and systemd's current authorization call supplies no unit-specific details (systemd D-Bus security, pinned systemd source). If passwordless delegation is later required, design a root-owned fixed-operation helper with a Fenris-specific polkit action.

Full primary-source research and planning sketches: systemd privilege lifecycle research.

Questions surfaced for the next Wayfinder session: minimum supported systemd/distribution set; stable device identity and transport matrix; whether a reduced-capability collector works portably; exact timer/resume semantics; whether disable-at-boot also needs a separately confirmed stop-now action; who may read health history; packaging paths; durability/migration policy; and whether ordinary admin authentication is acceptable. No map fog or tickets were changed for these questions.

Resolved [Verify systemd lifecycle and privilege constraints](https://git.bongbetic.com/xavierk/Fenris/issues/7). **Answer:** Use an enabled **system timer** plus a short-lived **system oneshot collector**. PID 1 should schedule collection after boot and periodically thereafter; the on-demand TUI stays unprivileged and independent. A user service would require lingering to survive logout/reboot and still cannot use `User=` to become root ([loginctl](https://www.freedesktop.org/software/systemd/man/latest/loginctl.html#enable-linger%20USER%E2%80%A6), [systemd.exec](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#User=)). The collector should invoke administrator-owned `smartctl` directly—never embedded `sudo`—and limit privileged work to fixed read-only device interrogation plus state writes. Put root-owned config in `/etc/fenris`, durable observations in `/var/lib/fenris`, ephemeral coordination in `/run/fenris`, and diagnostics in the journal ([systemd managed directories](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#RuntimeDirectory=), [FHS](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s08.html)). The TUI should read a sanitized status surface and query allow-listed `systemctl show` properties rather than scrape human-oriented `systemctl status` ([systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html#show%20PATTERN%E2%80%A6)). For explicit startup changes, have the TUI request `enable` or `disable` for the fixed Fenris timer and let normal polkit administrator authentication run. Keep enablement separate from current runtime state; `enable`/`disable` do not start/stop unless `--now` is explicitly used ([systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html#--now)). Do not grant a Fenris group the generic `org.freedesktop.systemd1.manage-unit-files` action: it governs unit-file operations broadly, and systemd's current authorization call supplies no unit-specific details ([systemd D-Bus security](https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.systemd1.html#Security), [pinned systemd source](https://github.com/systemd/systemd/blob/a6a831d0d9ce304619b8937b27b1286109b5e625/src/core/dbus-util.c#L209-L223)). If passwordless delegation is later required, design a root-owned fixed-operation helper with a Fenris-specific polkit action. Full primary-source research and planning sketches: [systemd privilege lifecycle research](https://git.bongbetic.com/xavierk/Fenris/src/branch/research/systemd-privilege-lifecycle/docs/research/systemd-privilege-lifecycle.md). **Questions surfaced for the next Wayfinder session:** minimum supported systemd/distribution set; stable device identity and transport matrix; whether a reduced-capability collector works portably; exact timer/resume semantics; whether disable-at-boot also needs a separately confirmed stop-now action; who may read health history; packaging paths; durability/migration policy; and whether ordinary admin authentication is acceptable. No map fog or tickets were changed for these questions.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Reference: xavierk/Fenris#7