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

[Thompson, David]

Hi Arun,

On Sat, Nov 25, 2023 at 7:00 PM Arun Isaac <arunisaac@systemreboot.net> wrote:
>
>
> 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).

I figured the existing users of this service had something like this
going on. I don't want to make the permissions looser on my own
server, though.

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

I also hack the nginx service to made the nginx user part of the git group:

https://git.dthompson.us/guix-config/tree/takemi-os.scm#n20

This hack causes all sorts of annoying side effects, which is why I
didn't want to go through it all again for the laminar service.

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

I agree that this indicates a missing means of composition, but in the
short term I think it's fine to do simple things that help people out
even though it's not the "right thing".

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

Providing a way to modify user accounts in services would be great!
It's not a problem I can work on solving, though, at least not now.

- Dave