GNU bug report logs -
#27155
[PATCH 0/2] Support service extensions on the "final" service values
Previous Next
Full log
Message #52 received at 27155 <at> debbugs.gnu.org (full text, mbox):
Hi,
Rutherther <rutherther <at> ditigal.xyz> 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’.
This bug report was last modified 50 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.