Additional group membership ignored?

LXC
1

I’m rather new to LXC and currently running LXC 5.0.3 on a host with a few running unprivileged containers started with lxc-execute as different users, and no idmaps. I want them to be unprivileged as I have no need for root privileges for anything.

One of the containers creates a UNIX socket with particular user:group permissions. Another container host another program that needs aforementioned UNIX socket. On the users are members of respective groups to grant access to the UNIX sockets, and it works on the host, but not in a container where they are denied by OS (Permission denied). If i manually chmod the UNIX socket files 666 after creation, the containers are allowed to use then with no problems.

This led me to believe additional group memberships are reset/dropped when creating a LXC container.

Is this true or am I missing something obvious?

2

I’d check the output of id in the connecting container against the uid/gid values of stat /path/to/socket in the target container.

3

/usr/bin/id from connecting container

uid=237(rspamd) gid=237(rspamd) groups=237(rspamd)

/usr/bin/stat /run/redis/redis-server.sock on target running container.

~ # lxc-attach -n redis -- /usr/bin/stat /run/redis/redis-server.sock
  File: /run/redis/redis-server.sock
  Size: 0         	Blocks: 0          IO Block: 4096   socket
Device: 0,20	Inode: 2786        Links: 1
Access: (0770/srwxrwx---)  Uid: (   75/   redis)   Gid: (   75/   redis)
Access: 2024-01-21 07:37:25.111451951 +0100
Modify: 2024-01-21 07:37:25.111451951 +0100
Change: 2024-01-21 07:37:25.111451951 +0100
 Birth: 2024-01-21 07:37:25.111451951 +0100
4

Right so the connecting user isn’t a member of group 75 which would explain why it can’t access the socket.

5

According to both the host and containers files, it should be a member

~ # cat /etc/group | grep redis
redis:x:75:rspamd
~ # cat /chroot/rspamd/etc/group | grep redis
redis:x:75:rspamd
~ # cat /chroot/redis/etc/group | grep redis
redis:x:75:rspamd
~ # getent group | grep rspamd
redis:x:75:rspamd
~ #
6

You may need to go through the PAM stack in the container to get the extra groups added to your session.

The easiest way to do this is by using the su command.

7

The easiest way to do this is by using the su command.

I’m not sure what you mean by that. How does su make that easier?

8

On Linux, extra groups are managed by userspace, not by the kernel.
PAM is what reads your /etc/group to look at your extra groups and add them to the current user during login.

When you use something like lxc-attach, you’re only dealing with what the kernel can do, so no extra groups.

But if as the root user in the container you spawn your unprivileged task through su NAME -c "command", then su will go through PAM, and so your user will get its extra groups initialized.

9

I guess that applies to all lxc-* commands?

10

Yeah, you need to go through the login stack inside the instance for things like groups, limits and other things to be applied to the user.

You can do that through su as mentioned before or by going through a full user login sequence by running login or by using SSH to enter the container.