Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final"

From: Ludovic Courtès <[email-masked]>
Date: Wed, 23 Apr 2025 12:00:20 +0200

Hi,

Rutherther <[email-masked]> writes:

>> With this extension, pretty much anything could happen.  The extra
>> flexibility could be put to good use, but we should also pay attention
>> to the cost and see if we can come up with less invasive alternatives.
>
> We already have something like this in pam service, the transformer
> field, I think that if other services started supporting that, it's
> basically the same as making a generic interface like this, except
> harder as each service has to do it on their own.

Yes, the ‘transformer’ field is exactly like this proposal, just limited
to PAM.

>> I think it’s an example that could be solved at the Shepherd level, by
>> attaching essentially a key/value store to each service (the mcron
>> service would query the ‘wayland-display’ value of the wayland service.)
>
> I think that anything we come up with can be solved at the service
> level, but I think that is besides the point,

Well yes, though I think that the WAYLAND_DISPLAY value is fundamentally
a run-time value, so it has to be solved though run-time mechanisms, in
the Shepherd.

>> Note that I was using NixOS too (but long ago), and the “ambient
>> authority” in the NixOS module system is one thing I definitely wanted
>> to avoid.  By “ambient authority” I mean that any module can change any
>> option of the global system config; there’s no way to track which module
>> does what, nor whether an option that is set is used at all.
>
> I definitely agree, and it's one of the reasons I switched to Guix
> System. But I don't think what this is adding is so similar to that
> though, because you still get that 'link' between the services that can
> be seen by the user in an 'extension' graph (or something new like
> finalizer graph)
> Also with this finalizers, it's still not possible to read values of
> services like NixOS allows.
> In NixOS, one 'service', A, can change B, and B can change A, leaving
> us with a mess, this is also something that will still not be allowed
> if finalizers are used.

I agree, finalizers are still less expressive than the NixOS module
system (which I think is good).  Yet, they can still do a lot and none
of that can be inferred by looking at the extension graph.

> Let me sketch few things I now lack in Guix System, all solvable by
> this, or on per-service basis:
>
> - Modifying shepherd services
>   - Auto start disable
>   - New env vars
>     - Ie. allowing programs to use GUI with DISPLAY
>   - Run as different user
>     - Security or convenience
>     - But this one suffers from another issue, where the user is
>       actually decided by the forkexec, so this one is more involved, it's
>       not trivial even with this change. So we will need shepherd support
> - Modifying users
>   - Add a group to a user
>     - To share a common socket file between two services

Hmm.  I think it would be interesting to prototype services that make
use of finalizers, to get a better idea of the possibilities it would
open.

> - Modifying existing pam rules

This one is handled by the ‘transformer’ field, right? :-)

> Apart from those use cases, one I am missing the most is the possibility
> to extend the least authority wrappers, but this one suffers from
> similar issue as running services as different user.

Extend how?

Thanks,
Ludo’.