guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#67288] [PATCH] services: laminar: Add configuration option for supp


From: Arun Isaac
Subject: [bug#67288] [PATCH] services: laminar: Add configuration option for supplementary groups
Date: Sun, 26 Nov 2023 00:00:23 +0000

Hi,

>> I started using Laminar CI for my personal server, but I had trouble
>> with the current system service. My server is configured to only allow
>> members of the "git" group access to the Git repositories, so the CI
>> job running as the "laminar" user couldn't do anything useful. This
>> patch adds a new configuration field for a list of supplementary
>> groups to be used for the "laminar" user and the service process.
>
> Cc’ing Arun and Chris, who know better than me.  Is this a problem they
> worked around so far?

This kind of problem requiring supplementary groups exists with many of
our services, not just the laminar service. I don't run into trouble
with the laminar service because git repos on my servers are usually
publicly readable by all users (including the laminar user).

To provide another example, I have similar trouble with our nginx
service not being able to access Unix sockets created by our fcgiwrap
service. Now, I work around this by having a special fcgiwrap service in
guix-forge[1]. This special guix-forge fcgiwrap service differs from the
guix fcgiwrap service in that it creates separate fcgiwrap instances for
each web application each with its own explicitly specified permissions.

[1]: https://git.systemreboot.net/guix-forge/tree/guix/forge/fcgiwrap.scm

I don't think the solution to this problem is to add a
`supplementary-groups' field to all our services. I'm not sure how, but
we need to compose things better. If we don't, we may find we need to
add some other field in the future and quickly be in a combinatorial
explosion.

Thinking out loud, the Guix service configuration system is really a
propagator network. So, maybe, the solution is to allow one service to
*extend* another service by specifying what supplementary groups it
should be a part of. This is more flexible than simply adding a
configuration field. Sorry to be quite vague here. Does this make any
sense? Happy to chat more.

Regards,
Arun





reply via email to

[Prev in Thread] Current Thread [Next in Thread]