Map all supplementary groups into the distro container as visible via POSIX identity management APIs.

[codonell]

On the host system the user deploying distrobox may have a number of important supplementary groups as part of their user setup.

Today distrobox maps only the primary group for the user into the distro container and an additional 'nobody' group which was not normally a secondary group for the user outside of the container.

In order to provide the user with the most flexibility to work with group-based access in the host filesystem the secondary groups must also be mapped.

I would like distrobox to attempt to map all of the users groups by default from the host into the container.

The alternative is that the user has to do this all themselves and I want to make distrobox one of the recommended solutions for building software inside a container.

Some additional context here, we recently had a developer using distrobox for upstream glibc development and they had several tests fail inside of a distrobox build. We realized that the problem was that secondary groups, some of which are needed to run certain tests that use fchown didn't work inside distrobox because it did not map all of the user's groups into the container. We are going to mark the test in question as unsupported when run under distrobox (https://sourceware.org/pipermail/libc-alpha/2023-May/148677.html), but it's something I think we can support to improve coverage here.

[codonell]

With respect to the glibc test it is sufficient in some cases (not all) to have a secondary group with enough permissions to be used with the filesystem. So for example when using other container tooling like toolbox it works because wheel is present as a functioning secondary group that the test infrastructure can attempt to use. This isn't the best solution, but it is workable compromise.

[89luca89]

Hi @codonell

this should be granted if you use crun as distrobox instructs podman to actually keep the groups

But be aware that the groups won't be "visible" inside the container, but access to files/dirs will be granted.

More info: https://www.redhat.com/sysadmin/supplemental-groups-podman-containers

[codonell]

this should be granted if you use crun as distrobox instructs podman to actually keep the groups
But be aware that the groups won't be "visible" inside the container, but access to files/dirs will be granted.

My apologies, let me clarify further (title edited).

It is a significant problem if the standard POSIX identity management APIs for this do not work as expected.

If getgroups doesn't list the group then no conforming application inside the container can assume it has access to the groups.

A well written test case will validate that it has all the preconditions for operation, and in the case of distrobox this will fail because the only visible supplementary group is "nobody" which does not meet the conditions required for testing.

So to clarify:

• Map all supplementary groups into the container.
• Make those groups visible to the POSIX identity management APIs.

Without such visibility we can't easily map the roles the user had into the container to execute the testing required for glibc tests to be run under distrobox.

[89luca89]

Hi @codonell

If I understand this correctly, if we have an user with:

groups: test-user
test-user: groupA,groupB,test-user

you need that groupA and groupB actually appear in the distrobox am I right?

Technically one could do a group with the same GID, but they are not actually mapped
This is a limitation on rootless podman's end (it maps numerically just your uid/gid, and the supplementary are nobody)
See here: containers/podman#13090

I think you can test this last thing with a simple --init-hooks like:

distrobox create -i image:tag -n test_container --init-hooks "groupadd -g UID NAME; groupadd -g UID2 NAME2" 

And see if this works for you (then we can find a better solution, it's just to test)

To have proper mapping between the groups inside/outside you'll have to either use docker or rootfull podman due to the limitation previously mentioned

[codonell]

If I understand this correctly, if we have an user with:

groups: test-user
test-user: groupA,groupB,test-user

you need that groupA and groupB actually appear in the distrobox am I right?

Correct.

Technically one could do a group with the same GID, but they are not actually mapped This is a limitation on rootless podman's end (it maps numerically just your uid/gid, and the supplementary are nobody) See here: containers/podman#13090

Thanks. Commented there.

I think you can test this last thing with a simple --init-hooks like:

distrobox create -i image:tag -n test_container --init-hooks "groupadd -g UID NAME; groupadd -g UID2 NAME2" 

And see if this works for you (then we can find a better solution, it's just to test)

It's a little more complicated, but essentially:

groupadd -g GID testgroup1
groupadd -g GID2 testgroup2
usermod -G testgroup1,testgroup2 $USER
su $USER

That is to say we need to add the groups from the host, and then modify the user to be in them, and then create a new login shell with the groups present.

To have proper mapping between the groups inside/outside you'll have to either use docker or rootfull podman due to the limitation previously mentioned

So long as the kernel lets the user process fchown to the reserved gid in the container then it should work for glibc.

[codonell]

... in fact it works in toolbox partly because they don't use the reserved nobody in the setup process, they use wheel for this case and that works enough for our testing scenarios because wheel is valid inside the container and part of the range of /etc/subgid.

[89luca89]

You're referring to the toolbx implementation?
I think they just add the user to the sudo/wheel group into the container, as distrobox just does the same thing as toolbx (which is the project I'm inspired by) using --userns keep-id option of podman.

In fact both in toolbx and distrobox this yelds the same result:

As the wheel group inside the container is not the same as outside
But then the access is granted by the crun supplementary group flag.

All in all I think adding the user to sudo/wheel is a sensible default, and I'll add it to the init

[89luca89]

@codonell I've added this in latest commit 9bfac5c
could you check if this behave like toolbox? thanks