#27155 [PATCH 0/2] Support service extensions on the "final" service values

Message #55 received at 27155@debbugs.gnu.org (full text, mbox, reply):

Received: (at 27155) by debbugs.gnu.org; 23 Apr 2025 16:40:27 +0000
From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 23 12:40:27 2025
Received: from localhost ([127.0.0.1]:58590 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1u7d96-00006k-6o
	for submit@debbugs.gnu.org; Wed, 23 Apr 2025 12:40:27 -0400
Received: from ditigal.xyz ([2a01:4f8:1c1b:6a1c::]:33690 helo=mail.ditigal.xyz)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <rutherther@ditigal.xyz>)
 id 1u7d90-0008Td-CJ
 for 27155@debbugs.gnu.org; Wed, 23 Apr 2025 12:40:22 -0400
Received: by cerebrum (OpenSMTPD) with ESMTPSA id 93dbf53f
 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO); 
 Wed, 23 Apr 2025 16:40:11 +0000 (UTC)
From: Rutherther <rutherther@ditigal.xyz>
To: Ludovic Courtès <ludo@gnu.org>
Subject: Re: bug#27155: [PATCH 0/2] Support service extensions on the "final"
In-Reply-To: <87bjsnp58r.fsf@gnu.org>
References: <87bju16vue.fsf@ditigal.xyz> <875xjbstgj.fsf@gnu.org>
 <87v7r1tssi.fsf@ditigal.xyz> <87bjsnp58r.fsf@gnu.org>
Date: Wed, 23 Apr 2025 18:40:08 +0200
Message-ID: <87ldrqygpj.fsf@ditigal.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ditigal.xyz;
 i=@ditigal.xyz; q=dns/txt; s=20240917; t=1745426411; h=from : to : cc
 : subject : in-reply-to : references : date : message-id :
 mime-version : content-type : content-transfer-encoding : from;
 bh=CrE2TjxtvmoI4G2Ttm14MQ/3vzoDb2M0xMKnax6o9lY=;
 b=fwM70htnLuVgEytz67bETxD7arERy1XVgJ5An7ch6UKW1BYQ37sN1xo0XKbSqkx+LK3Xs
 BhtiS25WHLZFPFhhuHy96i6sF7zz8EqmqeEsA5sXr7BdHrh5Qf7dADRdgpWYtm853uVurgH
 +CjkheCH3q1Efvv5QKqbekB6i/w4CN4=
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Hello, Ludovic Courtès <ludo@gnu.org> writes: > Hi, > > Rutherther
    <rutherther@ditigal.xyz> writes: > >>> 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 mc [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
X-Debbugs-Envelope-To: 27155
Cc: Ricardo Wurmus <rekado@elephly.net>, 27155@debbugs.gnu.org
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Hello, Ludovic Courtès <ludo@gnu.org> writes: > Hi, > > Rutherther
    <rutherther@ditigal.xyz> writes: > >>> 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 mc [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
  1.0 BULK_RE_SUSP_NTLD      Precedence bulk and RE: from a suspicious TLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

Hello,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Rutherther <rutherther@ditigal.xyz> writes:
>
>>> 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.

Could you clarify what run-time mechanism you have in mind here? I was
thinking in terms of how home-x11-display service does this, where you
need to go and set #:environment-variables in other services. Do you
have something more 'robust' in mind? I know that systemd has a function
to import environment `systemctl import-environment`, on the other hand
I don't really like that you just import the env vars everywhere instead
of having more controlled approach where the service says what to get
from where.

>
>>> 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.

I am not sure if my initial point got through, or not, so I will try to
rephrase, in case it already got through to you, and you just wanted to
extend on it, just ignore this:

Currently extensions can do transformations already, ie. the pam service
does that. This makes the extension graph less clear already in the same
way global finaliers would. But I would argue that the current approach
may be making the extension graph even less clear than a global
finalizers, because it's not known which services are extending the
'transformator' and which ones just the normal options. By having a more
global finalizer/transformer approach, it would be something that can be
marked in the graph, and we can distinguish between regular extensions
and finalizers. (of course only given that no one will make a
transformer-like extension support in their service, but at least in
Guix channel itself this could be made sure of, and I don't think anyone
would try that if there was a global approach)

>
>> 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.
>

Yeah, that makes sense. Unfortunately I won't be able to get to this any
time soon I am afraid.

>> - Modifying existing pam rules
>
> This one is handled by the ‘transformer’ field, right? :-)

Yeah, my point was that this makes it more generic.

>
>> 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?

For example to share files, like sockets, between two services.

In NixOS I have opensmtpd, and it contacts my sourcehut instance
by a socket when an e-mail is received. Socket needs to be shared
between those two. I do this in my config:
```
  systemd.services = {
    listssrht-ingress = {
      unitConfig.JoinsNamespaceOf = "opensmtpd.service";
    };
    todosrht-lmtp = {
      unitConfig.JoinsNamespaceOf = "opensmtpd.service";
    };
    opensmtpd = {
      # Needed for sharing the LMTP sockets with JoinsNamespaceOf=
      serviceConfig.PrivateTmp = true;
    };
  };
```
Which will make /tmp of the services shared (this can be made in
multiple ways of course, this is just one possibility, it could also be
a commonly mapped folder, no need for it to be /tmp), so that the socket
under /tmp is visible by both and they can communicate with each other.

Best regards,
Rutherther

Send a report that this bug log contains spam.