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

Hey everyone,

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.

- Dave

Hi,

"Thompson, David" <dthompson2@worcester.edu> skribis:

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

> From ed62d885a5493f64779bc9c2a9b9978af8f61824 Mon Sep 17 00:00:00 2001
> Message-ID: <ed62d885a5493f64779bc9c2a9b9978af8f61824.1700423610.git.dthompson2@worcester.edu>
> From: David Thompson <dthompson2@worcester.edu>
> Date: Sun, 19 Nov 2023 14:46:52 -0500
> Subject: [PATCH] services: laminar: Add configuration option for supplementary
>  groups.
>
> * gnu/services/ci (<laminar-configuration>)[supplemental-groups]: New field.
> (laminar-shepherd-service): Exec laminard with supplementary groups.
> (laminar-account): Add supplementary groups to laminar user.
> * doc/guix.texi (Laminar): Document new configuration field.

[...]

> +@item @code{supplementary-groups} (default: @code{()})
> +Supplementary groups for the Laminar user account.

Perhaps mention the “git” group example you gave above?

Otherwise looks pretty harmless to me.

Ludo’.

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

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

Hi David,

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

In my case, the git repos are for publishing online. So, global read
permissions are acceptable. I understand your situation may be
different.

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

I agree.

Regards,
Arun

Hi David,

>> 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".
>
> I agree.

Please go ahead and push this patch if everything else checks out. I
don't mean to block this patch.

Thanks,
Arun

Hi Arun,

On Wed, Dec 6, 2023 at 8:19 AM Arun Isaac <arunisaac@systemreboot.net> wrote:
>
>
> Hi David,
>
> >> 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".
> >
> > I agree.
>
> Please go ahead and push this patch if everything else checks out. I
> don't mean to block this patch.

Okay, pushed! Thanks!

- Dave