On Tue, Sep 10, 2024 at 5:51 PM Divine Eguzouwa <divine.eguzouwa@xxxxxxxxx> wrote:
Assuming: run0 (and all of systemd for that matter) security works by sandboxing a service's "cgroup-namespace environment" (i.e., through User=/Group=, and/or NoNewPrivilages=, and/or etc.) and directly executing the given command therin...
Most of those parameters actually have nothing to do with cgroups. For example, User= is just a regular process-level setreuid(), the same as you would get from doas/su/runuser.
I have a chain of services that executes a process belonging to User=/Group=one, that will read from a specific directory belonging to User=/Group=two, subsequently resulting in running a /bin executable that belongs to User=/Group=ANYPlease walk me through how to model run0 --user to accomplish this in an "environment" without authentication? So far I keep bumping into "Failed to start transient service unit: Interactive authentication required." errors which leads me to believe that my earlier assumption is incorrect
I don't think run0 is meant for such use at all; starting transient services in batch would be better done through systemd-run (or the corresponding D-Bus API) – assuming you need them to be independent services at all, that is.
Both use the same authorization method (PolicyKit) – you could write an /etc/polkit-1 rule to allow a certain user to create transient units – but I don't know if that can be granular enough to only allow userA>userB transitions. Most likely it will be "all or nothing", i.e. if you allow userA to call run0/systemd-run, that user will be able to become *any* user... A chain of predefined .service units might work better.
--
Mantas Mikulėnas
