On Tue, Sep 10, 2024 at 5:51 PM Divine Eguzouwa <divine.eguzo...@gmail.com> 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=ANY > > Please 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
