Sharing X11 socket as unprivileged user fails with "Can't open display"

[hkjn]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

On a Debian Bullseye host, sharing the /tmp/.X11-unix socket with a container fails to open X11 apps if a non-privileged user is used inside the container. Issue can seemingly be worked around using root to execute podman run on the host, but since same recipe works in Docker and podman / container processes clearly can access the socket this seems like a potential bug / area of improvement.

Steps to reproduce the issue:

Given Dockerfile like:

FROM docker.io/debian:bullseye-slim

RUN apt update && \
    apt install --no-install-recommends -y x11-apps && \
    useradd --create-home --home-dir /home/user user && \
    chown -R user:user /home/user

USER user

CMD ["xclock"]

Build and run the image:

$ podman build -t x11 .
$ podman run -it --rm -v /tmp/.X11-unix:/tmp/.X11-unix:rw -e DISPLAY x11
No protocol specified
Error: Can't open display: :0.0

So this fails. However, running as root inside the container succeeds:

$ podman run -u 0 -it --rm -v /tmp/.X11-unix:/tmp/.X11-unix:rw -e DISPLAY x11

The app I am switching from docker to podman is Tor Browser, which doesn't like running as root. I'm showing the issue with xclock above instead for a simpler repro case.

So with podman running as my non-privileged user on my host, it can access the X11 socket as root inside the container.

Interestingly, if I execute the podman run as root on the host, X11 apps work even as non-privileged user inside the container.

File ownership of /tmp/.X11-unix is root on the host, and with the podman run command executed as non-privileged user it ends up being mapped to nobody inside the container:

user@e1f6091fec8b:/$ ls -hsal /tmp/.X11-unix/
total 8.0K
4.0K drwxrwxrwt 2 nobody nogroup 4.0K Jan 27 12:06 .
4.0K drwxrwxrwt 3 root   root    4.0K Jan 27 12:29 ..
   0 srwxrwxrwx 1 nobody nogroup    0 Jan 10 11:33 X0
user@e1f6091fec8b:/$ id nobody
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)

Inside the container created with podman run executed as root on the host, file ownership is preserved as root inside the container:

user@ef62dd411ee8:/$ ls -hsal /tmp/.X11-unix/
total 8.0K
4.0K drwxrwxrwt 2 root root 4.0K Jan 27 12:06 .
4.0K drwxrwxrwt 1 root root 4.0K Jan 27 12:27 ..
   0 srwxrwxrwx 1 root root    0 Jan 10 11:33 X0

The non-privileged user in the container ends up with uid:gid 1000:1000 in both cases, which matches the non-privileged user on the host, if that matters.

Describe the results you received:

Error message when non-root user runs X11 apps.

Describe the results you expected:

No error.

Output of podman version:

Version:      3.0.1
API Version:  3.0.0
Go Version:   go1.15.9
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.19.6
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 8
  distribution:
    distribution: debian
    version: "11"
  eventLogger: journald
  hostname: velletri
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.10.0-10-amd64
  linkmode: dynamic
  memFree: 2311110656
  memTotal: 16520138752
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.17
      commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    selinuxEnabled: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.0.1
      commit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4
      libslirp: 4.4.0
  swapFree: 46702592
  swapTotal: 1023406080
  uptime: 408h 45m 18.62s (Approximately 17.00 days)
registries: {}
store:
  configFile: /home/user/.config/containers/storage.conf
  containerStore:
    number: 3
    paused: 0
    running: 0
    stopped: 3
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: 'fuse-overlayfs: /usr/bin/fuse-overlayfs'
      Version: |-
        fusermount3 version: 3.10.3
        fuse-overlayfs: version 1.4
        FUSE library version 3.10.3
        using FUSE kernel interface version 7.31
  graphRoot: /home/user/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 53
  runRoot: /run/user/1000/containers
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 3.0.0
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.15.9
  OsArch: linux/amd64
  Version: 3.0.1

Package info (e.g. output of rpm -q podman or apt list podman):

$ apt list podman
Listing... Done
podman/stable,now 3.0.1+dfsg1-3+b2 amd64 [installed]

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Checked the guide, did not try building from latest commit yet.

#5226 seems related in terms of symptoms, but the suggested workarounds there (--security-opt label=disable, --privileged) does not alter the outcome here.

Additional environment details (AWS, VirtualBox, physical, etc.):

Physical host

[debarshiray]

I vaguely remember looking into something like this in the past, but I can't remember what the missing piece was. You can:

• Try running strace against xclock.
• See what Toolbx does.

... or just use Flatpak?

[hkjn]

recvfrom(3, "\0\26\v\0\0\0\6\0", 8, 0, NULL, NULL) = 8
recvfrom(3, "No protocol specified\n\0\0", 24, 0, NULL, NULL) = 24

Ah, searching that error leads to this stackexchange reply, which suggests running xhost + to let X11 clients connect from remote hosts.

If I run this the non-privileged case indeed succeeds, but since it also weakens security, I'm still curious why it's needed with podman?

[rhatdan]

The :0.0 would be fixed via --net=host, which would put the processes on the same network. And should not require the xhost+

[edsantiago]

I haven't been following this discussion closely, but I see no .Xauthority in your podman command line. I get X11 working on my systems by adding -v $HOME/.Xauthority:/root/.Xauthority:z

[hkjn]

Thanks, both, but neither --net=host nor mapping in the $HOME/.Xauthority file changes the outcome. Seems like adding --uidmap and --gidmap incantations as appropriate solves it though, see the other reply which I marked as the answer.

[debarshiray]

I can install toolbox, but what are you suggesting I do with it?

Toolbx uses Podman, and I do expect this scenario to work inside Toolbx containers. If it doesn't then, feel free to open a bug.

So, I was suggesting that you dig into how Toolbx is using Podman to make this possible. :)

[rhatdan]

My guess is something to do with user namespace or with other namespaces.
You could try with --net=host --ipc=host --pid=host

[hkjn]

--net=host --ipc=host --pid=host

Thanks for the suggestion, but there's no difference in outcome by adding these flag.

[rhatdan]

This is a discussion though not an issue.

[eriksjolund]

I think you need to map the host user to the user in the container (UID=1000, GID=1000) with --uidmap.

Using --gidmap does not seem to be necessary in this case, but I add it to make the solution below a bit more general.

uid=1000
gid=1000
subuidSize=$(( $(podman info --format "{{ range .Host.IDMappings.UIDMap }}+{{.Size }}{{end }}" ) - 1 ))
subgidSize=$(( $(podman info --format "{{ range .Host.IDMappings.GIDMap }}+{{.Size }}{{end }}" ) - 1 ))
podman run \
         --rm \
         -e DISPLAY \
         --net=host \
         -v ~/.Xauthority:/home/user/.Xauthority:z \
         --uidmap $uid:0:1 \
         --uidmap 0:1:$uid \
         --uidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid)) \
         --gidmap $gid:0:1 \
         --gidmap 0:1:$gid \
         --gidmap $(($gid+1)):$(($gid+1)):$(($subgidSize-$gid)) \
           localhost/xclock

The same commands on a single line:

uid=1000; gid=1000; subuidSize=$(( $(podman info --format "{{ range .Host.IDMappings.UIDMap }}+{{.Size }}{{end }}" ) - 1 )); subgidSize=$(( $(podman info --format "{{ range .Host.IDMappings.GIDMap }}+{{.Size }}{{end }}" ) - 1 )) ; podman run --rm -e DISPLAY --net=host -v ~/.Xauthority:/home/user/.Xauthority:z  --uidmap $uid:0:1  --uidmap 0:1:$uid --uidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid)) --gidmap $gid:0:1 --gidmap 0:1:$gid --gidmap $(($gid+1)):$(($gid+1)):$(($subgidSize-$gid)) localhost/xclock

I tried it out by logging in to a test user on my laptop with

ssh -Y [email protected]

Starting xclock with the commands above worked. A window was shown with an analog clock.
I had hoped that pressing Ctrl-C would make the program exit but it kept running. (I also tried adding -ti but it did not help).

My laptop is running Fedora 35.

[hkjn]

--gidmap $(($gid+1)):$(($gid+1)):$(($subgidSize-$gid))

Thank you, adding the --uidmap and --gidmap flags solves the issue.

Using id command inline, what I ended up with as a minimally working example was:

$ podman run --rm --name x11debug --uidmap $(id -u):0:1 --gidmap $(id -g):0:1 --gidmap 0:1:$(id -g) -it -v /tmp/.X11-unix:/tmp/.X11-unix:ro -e DISPLAY x11

(Reading the docs, I'm unsure why the second --gidmap 0:1:$(id -g) is needed, actually, but then again I don't really understand user namespaces..)

So my understanding is that the /tmp/.X11/X0 socket was readable by the non-privileged user running in the container, but X11 refused the connection because of a mismatch in uid / gid compared to what it expected? That's my inference based on the behavior, and the info from the other comment:

recvfrom(3, "\0\26\v\0\0\0\6\0", 8, 0, NULL, NULL) = 8
recvfrom(3, "No protocol specified\n\0\0", 24, 0, NULL, NULL) = 24

Ah, searching that error leads to this stackexchange reply, which suggests running xhost + to let X11 clients connect from remote hosts.

I'll mark this reply as the answer, thank you again.

While it does make sense that the behavior of podman diverges from docker here, since podman uses user namespaces, it seems pretty tricky to diagnose what's going on, and to get the --uidmap and --gidmap flags just right.

Would it make sense to add something to docs about this for other users who might stub their toes on this, perhaps in troubleshooting.md? (I'd be happy to send the PR, modulo not really understanding user namespaces well enough to know what's the best general incantation for this case.)

[eriksjolund]

@hkjn I had some documentation text written about --uidmap and --gidmap so I took some of that and created a draft PR #13084 to add an item to the troubleshooting guide. The other text I was writing contained more text and examples. Something that might be useful for https://docs.podman.io/en/latest/Tutorials.html. I think I'll add that one as a draft PR too.

Another experiment: I tried to log in with ssh -Y to a VM running Fedora CoreOS (next stream) and then start your xclock container.
I noticed that xauth was not installed which made X11 forwarding not work. To fix that I had to add the xauth RPM by following this scheme https://docs.fedoraproject.org/en-US/fedora-coreos/os-extensions/#_example_layering_vim_and_setting_it_as_the_default_editor
Opening the xclock window then worked.

I removed some command-line arguments. This works too:

uid=1000; podman run --rm -e DISPLAY --net=host -v ~/.Xauthority:/home/user/.Xauthority:Z --uidmap $uid:0:1 --uidmap 0:1:$uid  localhost/xclock

(z could be replaced with Z but using ro gave me X11 connection rejected because of wrong authentication)