[GH-ISSUE #1741] --x11=xorg can't connect to X on Arch

gitea-mirror commented

2026-05-05 07:36:34 -06:00

Owner

Originally created by @eevee on GitHub (Jan 20, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1741

$ firejail --debug --noprofile --x11=xorg bash
# ...
DISPLAY=:0 parsed as 0
Generating a new .Xauthority file
Username eevee, no supplementary groups
# this is from xauth
Using authority file /tmp/.tmpXauth-nU7msg
No protocol specified
/usr/bin/xauth: (argv):1:  unable to open display ":0".
# this is from firejail
Failed to create untrusted X cookie: xauth: exit 1
Error: proc 9738 cannot sync with peer: unexpected EOF
Peer 9739 unexpectedly exited with status 1

I can run the exact same xauth command from within firejail --noprofile bash, so the problem is something that only happens when firejail itself runs xauth.

xhost +si:localuser:$USER seems to fix it (at the cost of a less secure X), which suggests an access control problem… though the error doesn't mention access control. I notice my $XAUTHORITY points to a file in /tmp, which seemed suspicious since firejail shadows /tmp with a tmpfs while running xauth, but setting XAUTHORITY=$HOME/.Xauthority doesn't change anything. I don't know enough about X guts to speculate further. :)

I'm on Arch using firejail 0.9.52. I can't think of anything strange I've done to X that might be responsible. A brief poll of my followers found that it works for someone on Ubuntu but doesn't work for another Arch user, so I'm tempted to blame Arch?

Originally created by @eevee on GitHub (Jan 20, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1741 ``` $ firejail --debug --noprofile --x11=xorg bash # ... DISPLAY=:0 parsed as 0 Generating a new .Xauthority file Username eevee, no supplementary groups # this is from xauth Using authority file /tmp/.tmpXauth-nU7msg No protocol specified /usr/bin/xauth: (argv):1: unable to open display ":0". # this is from firejail Failed to create untrusted X cookie: xauth: exit 1 Error: proc 9738 cannot sync with peer: unexpected EOF Peer 9739 unexpectedly exited with status 1 ``` I can run the exact same xauth command from within `firejail --noprofile bash`, so the problem is something that only happens when firejail _itself_ runs xauth. `xhost +si:localuser:$USER` seems to fix it (at the cost of a less secure X), which suggests an access control problem… though the error doesn't mention access control. I notice my `$XAUTHORITY` points to a file in `/tmp`, which seemed suspicious since firejail shadows `/tmp` with a tmpfs while running xauth, but setting `XAUTHORITY=$HOME/.Xauthority` doesn't change anything. I don't know enough about X guts to speculate further. :) I'm on Arch using firejail 0.9.52. I can't think of anything strange I've done to X that might be responsible. A brief poll of my followers found that it [works for someone on Ubuntu](https://twitter.com/i2at7v/status/954601391812743168) but [doesn't work for another Arch user](https://twitter.com/reacocard/status/954603115335925760), so I'm tempted to blame Arch?

gitea-mirror added the

information_old

label 2026-05-05 07:36:34 -06:00

gitea-mirror commented

2026-05-05 07:36:37 -06:00

Author

Owner

@eevee commented on GitHub (Jan 20, 2018):

Ah, it looks like xhost circumvents the custom authority file entirely; with it, xterm runs fine (the manpage says it crashes) and I can read keystrokes from other clients with xinput test. Well, damn.

@eevee commented on GitHub (Jan 20, 2018): Ah, it looks like `xhost` circumvents the custom authority file entirely; with it, xterm runs fine (the manpage says it crashes) and I can read keystrokes from other clients with `xinput test`. Well, damn.

gitea-mirror commented

2026-05-05 07:36:38 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 3, 2018):

The most secure way to go is a simple xterm in xpehyr (xorg-server-xephyr package in Arch). Replace eth0 with your ethernet interface:

$ firejail --x11=xephyr --net=eth0 xterm

I have no idea what is happening when you go directly with bash, instead of a real x11 program. Your terminal is still running in the old X11 session, so there could be some interactions there.

@netblue30 commented on GitHub (Feb 3, 2018): The most secure way to go is a simple xterm in xpehyr (xorg-server-xephyr package in Arch). Replace eth0 with your ethernet interface: ````` $ firejail --x11=xephyr --net=eth0 xterm ````` I have no idea what is happening when you go directly with bash, instead of a real x11 program. Your terminal is still running in the old X11 session, so there could be some interactions there.

gitea-mirror commented

2026-05-05 07:36:40 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (May 29, 2019):

@eevee, is this still an issue for you?

@chiraag-nataraj commented on GitHub (May 29, 2019): @eevee, is this still an issue for you?

gitea-mirror commented

2026-05-05 07:36:42 -06:00

Author

Owner

@BetaRays commented on GitHub (Jul 29, 2019):

The problem also appears on Gentoo using sys-apps/firejail-0.9.60. It seems the .Xauthority file isn't accessible when running xauth, as running XAUTHORITY= xauth -v -f "$(mktemp)" generate :0 MIT-MAGIC-COOKIE-1 untrusted gives the same error (but running it with the previous XAUTHORITY variable set seems to work).

@BetaRays commented on GitHub (Jul 29, 2019): The problem also appears on Gentoo using `sys-apps/firejail-0.9.60`. It seems the .Xauthority file isn't accessible when running `xauth`, as running `XAUTHORITY= xauth -v -f "$(mktemp)" generate :0 MIT-MAGIC-COOKIE-1 untrusted` gives the same error (but running it with the previous XAUTHORITY variable set seems to work).

gitea-mirror commented

2026-05-05 07:36:43 -06:00

Author

Owner

@l29ah commented on GitHub (Sep 11, 2019):

I observe the same problem in my Gentoo on 0.9.61.

@l29ah commented on GitHub (Sep 11, 2019): I observe the same problem in my Gentoo on 0.9.61.

gitea-mirror commented

2026-05-05 07:36:45 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 8, 2019):

Is it possible you added a -nolisten local to the Xorg command line? There is an identical issue when x11 xorg is combined with any of the net options.

In this case there is no abstract X11 socket, which in turn means that when Firejail temporarily mounts a tmpfs on /tmp, the X11 socket in /tmp/.X11-unix is covered and xauth cannot connect. One possible solution is to simply mount the X11 socket on the tmpfs, so we are sure xauth can see it.

@smitsohu commented on GitHub (Oct 8, 2019): Is it possible you added a `-nolisten local` to the Xorg command line? There is an identical issue when` x11 xorg` is combined with any of the `net` options. In this case there is no abstract X11 socket, which in turn means that when Firejail temporarily mounts a tmpfs on /tmp, the X11 socket in /tmp/.X11-unix is covered and xauth cannot connect. One possible solution is to simply mount the X11 socket on the tmpfs, so we are sure xauth can see it.

gitea-mirror commented

2026-05-05 07:36:47 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 8, 2019):

the X11 socket in /tmp/.X11-unix is covered and xauth cannot connect

Anyway, that's a bug! I will push a fix. Probably it's easiest to generate the new Xauthority file in /run/firejail/mnt, where we have a multi-purpose tmpfs mounted already.

@smitsohu commented on GitHub (Oct 8, 2019): > the X11 socket in /tmp/.X11-unix is covered and xauth cannot connect Anyway, that's a bug! I will push a fix. Probably it's easiest to generate the new Xauthority file in /run/firejail/mnt, where we have a multi-purpose tmpfs mounted already.

gitea-mirror commented

2026-05-05 07:36:48 -06:00

Author

Owner

@l29ah commented on GitHub (Feb 15, 2020):

Still doesn't work on today's master.

Is it possible you added a -nolisten local to the Xorg command line?

Nope:

root      9776  2.5  0.4 188016 81036 tty1     Sl   Feb13  72:43 X :1 vt1 -nolisten tcp -br -auth /home/l29ah/.Xauthority

∞ netstat -nlp | grep /X
unix  2      [ ACC ]     STREAM     LISTENING     23851    9776/X               /tmp/.X11-unix/X1
unix  2      [ ACC ]     STREAM     LISTENING     23850    9776/X               @/tmp/.X11-unix/X1

@l29ah commented on GitHub (Feb 15, 2020): Still doesn't work on today's master. > Is it possible you added a -nolisten local to the Xorg command line? Nope: ``` root 9776 2.5 0.4 188016 81036 tty1 Sl Feb13 72:43 X :1 vt1 -nolisten tcp -br -auth /home/l29ah/.Xauthority ``` ``` ∞ netstat -nlp | grep /X unix 2 [ ACC ] STREAM LISTENING 23851 9776/X /tmp/.X11-unix/X1 unix 2 [ ACC ] STREAM LISTENING 23850 9776/X @/tmp/.X11-unix/X1 ```

gitea-mirror commented

2026-05-05 07:36:50 -06:00

Author

Owner

@moll commented on GitHub (May 27, 2020):

I can confirm that --x11=xorg with Firejail v0.9.62 fails with the same "unable to open display" error talked about above due to the xauth invocation in d1967d21f4/src/firejail/x11.c (L1201) probably not having access to the original authority file.

@moll commented on GitHub (May 27, 2020): I can confirm that `--x11=xorg` with Firejail v0.9.62 fails with the same "unable to open display" error talked about above due to the `xauth` invocation in https://github.com/netblue30/firejail/blob/d1967d21f4a929c0963d546e051e88dc2002966e/src/firejail/x11.c#L1201 probably not having access to the original authority file.

gitea-mirror referenced this issue

2026-05-05 10:09:25 -06:00

[PR #1181] [MERGED] restrict more KDE files #3867

Rows
Columns

[GH-ISSUE #1741] --x11=xorg can't connect to X on Arch #1181