[systemd-devel] Learning Help: modeling system-user services with `run0`

[Mantas Mikulėnas]

On Tue, Sep 10, 2024 at 5:51 PM Divine Eguzouwa <divine.eguzouwa at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240910/155d827a/attachment.htm>