Verify systemd lifecycle and privilege constraints #7
Notifications
Due Date
No due date set.
Blocks
#8 Define the collector, service, and CLI lifecycle
xavierk/Fenris
Reference: xavierk/Fenris#7
Reference in New Issue
Block a user
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.
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
smartctldirectly—never embeddedsudo—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-listedsystemctl showproperties rather than scrape human-orientedsystemctl status(systemctl).For explicit startup changes, have the TUI request
enableordisablefor the fixed Fenris timer and let normal polkit administrator authentication run. Keep enablement separate from current runtime state;enable/disabledo not start/stop unless--nowis explicitly used (systemctl). Do not grant a Fenris group the genericorg.freedesktop.systemd1.manage-unit-filesaction: 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.