Host id is in the range of subids when launching gui profile and high uid (SSSD)

LXD
,
1

Hi
I’m using the snap version of LXD and tried to follow the howto here: https://blog.simos.info/how-to-easily-run-graphics-accelerated-gui-apps-in-lxd-containers-on-your-ubuntu-desktop/

I didnt add the subuid and subgid lines since this is a snap install (though adding them doesnt fix the issue anyway)

Since this is authenticated to AD via SSSD, the user that runs LXD has a high uid, maybe this is a problem?

Here’s the profile I’m trying to use:
‘’’
config:
environment.DISPLAY: :0
raw.idmap: both 131204108 1000
user.user-data: |
#cloud-config
runcmd:
- ‘sed -i “s/; enable-shm = yes/enable-shm = no/g” /etc/pulse/client.conf’
- ‘echo export PULSE_SERVER=unix:/tmp/.pulse-native | tee --append /home/ubuntu/.profile’
packages:
- x11-apps
- mesa-utils
- pulseaudio
description: GUI LXD profile
devices:
PASocket:
path: /tmp/.pulse-native
source: /run/user/131204108/pulse/native
type: disk
X0:
path: /tmp/.X11-unix/X0
source: /tmp/.X11-unix/X0
type: disk
mygpu:
type: gpu
name: gui
used_by: []
‘’’

When launching a container, I get this error:
Error: Failed instance creation: Create instance: Create instance: Host id is in the range of subids

I’m not sure what Host id means here - can anyone help?

Thanks,

2

Hi!

If you can grab the source of LXD, search for this error message and see whether the check is a blanket check (i.e. LXD just does not like IDs bigger than 65535).

I am not familiar with SSSD; does the /etc/passwd of the user account contain that UID?

3

Thanks @simos

I cant see anything very obvious (but I’m not a go expert) - it seems like it this is where I’m getting stuck: https://github.com/lxc/lxd/blob/5b886473ec08622a7e1dec3891dc34d32b65a2f3/shared/idmap/idmapset_linux.go#L72-L87, but having to read up about golang a bit to figure out why (and what IDs its comparing) :slight_smile:

PS SSSD here is similar to winbind’s idmap_rid - it generates an ID based on the active directory sid of the user (and ends up with quite large IDs). /etc/passwd does not contain any entries for the user/UID

4

The code is OK. I suppose the issue is with the 1000, which refers to the GID on the host, not the UID in the container. Try to replace the 1000 with the appropriate value and check again.

5

One workaround for such cases would be:

  • lxc config set NAME security.idmap.isolated=true
  • lxc config set NAME security.idmap.base=200000000

That will put your container past your host used uid/gid.

I’m a bit surprised of you getting such a high uid/gid through SSSD though, in my case, they’re in the 200000 -> 500000 range so far below LXD’s first uid/gid.

2 Likes
6

thanks @stgraber - will this break my attempt to get graphical apps working, as I need to map to the “real” user running X?

7

I did not realise that - thanks. I’ve set it to “raw.idmap: both 131204108 131200514” in the profile now (user’s UID and “domain users” GID), but still get the same error. I tried restarting snap.lxd.daemon as well.

8

No, your raw.idmap entry should work fine even with those keys set.

9

In that case, you can avoid using idmap, and configure .Xauthority instead.

Your host’s X server, if you are using Ubuntu, has a configuration that allows access to the X11 Unix socket as long as the UID of the process that performs the access, is the same as the UID of the logged-in user. Other distributions may not have that.

Therefore, by using idmap, we are tricking the host’s X Server by making the container access the Unix socket with the same UID as the logged-in user on the host.

Since you are getting an error, you can fallback to the security mechanism, using the .Xauthority file.
The logged-in user on the host has a .Xauthority file that has inside a secret key (a cookie). Therefore, you can share this .Xauthority file to the container, and processes in the container will be now allowed to access the X server on the host.

To use .Xauthority, see the older guide at https://blog.simos.info/how-to-run-wine-graphics-accelerated-in-an-lxd-container-on-ubuntu/ and perform just the part with sharing the .Xauthority file to the container. You can remove the idmap configuration.

10

Thanks @stgraber and @simos (and sorry if some of my questions are a bit naive!) - i can now launch containers with my “gui” profile, but its not finding display 0, this is progress at least :smiley:

Here is my current “gui” profile:

    config:
      environment.DISPLAY: :0
      raw.idmap: both 131204108 131200514
      security.idmap.base: "200000000"
      security.idmap.isolated: "true"
      user.user-data: |
    #cloud-config
    runcmd:
      - 'sed -i "s/; enable-shm = yes/enable-shm = no/g" /etc/pulse/client.conf'
      - 'echo export PULSE_SERVER=unix:/tmp/.pulse-native | tee --append /home/ubuntu/.profile'
    packages:
      - x11-apps
      - mesa-utils
      - pulseaudio
    description: GUI LXD profile
    devices:
      PASocket:
    path: /tmp/.pulse-native
    source: /run/user/131204108/pulse/native
    type: disk
      X0:
    path: /tmp/.X11-unix/X0
    source: /tmp/.X11-unix/X0
    type: disk
      mygpu:
    type: gpu
    name: gui
    used_by:
    - /1.0/instances/ubugui

Here’s my attempt at running glxgears with this profile:
lxc exec ubukeybase – sudo --login --user ubuntu
To run a command as administrator (user “root”), use "sudo ".
See “man sudo_root” for details.

ubuntu@ubukeybase:~$ glxgears 
No protocol specified
Error: couldn't open display :0

If i swtich the profile to raw.idmap: both 131204108 1000 it runs xcalc ok (glxgears complains but i think im getting closer)

PS @simos is this info correct? We discussed that the “1000” in my idmap was for the host GID, not the container, but from https://blog.simos.info/how-to-easily-run-graphics-accelerated-gui-apps-in-lxd-containers-on-your-ubuntu-desktop/
The raw.idmap has a value that refers to the sets of $UID/$GID of the non-root user on the host and in the container. By default on Ubuntu the default ID for the first non-root account is 1000 (both user ID and group ID). This is necessary for the bind-mounting of sockets of the host to the container. If you need to change it, here is how to do it. Because we use the both keyword, the first number (i.e. 1000) is the $UID/$GID on the host, and the second number (i.e. 1001) is the $UID/$GID of the non-user account in the container.

11

Thanks for this - trying to make it work now. If i remove the idmap part, i see the .Xauthority file as owned by the host UID (the big uid), with the container/ubuntu user not having read access, is there a trick to this?

12

If you are using the snap package of LXD (channel stable), you can try the latest guide at https://blog.simos.info/running-x11-software-in-lxd-containers/
Here, we use LXD proxy devices, which means that we do not need IDMAPs anymore. The proxy devices deal with the appropriate IDs. That is, instead of bind-mounting the necessary files from the host to the container, you will be using proxy devices to expose them to the container.

If you managed to get xclock to work in the container, it means that X is working OK. If glxgears is not working, then this is an issue with hardware acceleration (GLX), and needs other steps (i.e. which GPU and driver?).

1 Like
13

This was the one I used to get it working - thanks @simos, much appreciated.

As a summary for anyone with similar issues: Stop fighting with id maps and use the proxy device for X11 as per: https://blog.simos.info/running-x11-software-in-lxd-containers/

PS pay careful attention to the instructions, some UIDs in the profile refer to container, and some to guest, if you’re not UID 1000 in the host, and running on DISPLAY :1 you’ll need to edit the examples