Cannot run Wayland application over X11/Xorg session

[8nvHHobXJ1KS]

I'm coming from Firejail and I have a problem when I try to run Wayland applications over a X11/Xorg session (say, a LXDE session) it is unable to run it, but the same script runs perfectly over a Wayland session (such as Enlightenment or Sway). Look at this example:

#!/bin/sh

bwrap \
    --unshare-all \
    --share-net \
    --new-session \
    --die-with-parent \
    --hostname localhost \
    --dev /dev \
    --proc /proc \
    --tmpfs /tmp \
    --symlink /usr/lib64 /lib64 \
    --ro-bind /usr/lib64/ /usr/lib64 \
    --symlink /usr/bin /bin \
    --ro-bind /usr/bin/env /usr/bin/env \
    --ro-bind /usr/bin/sh /usr/bin/sh \
    --ro-bind /usr/bin/bash /usr/bin/bash \
    --ro-bind /usr/bin/id /usr/bin/id \
    --ro-bind "/usr/bin/[" "/usr/bin/[" \
    --ro-bind /usr/bin/grep /usr/bin/grep \
    --ro-bind /usr/bin/sed /usr/bin/sed \
    --ro-bind /usr/bin/dirname /usr/bin/dirname \
    --ro-bind /usr/bin/mkdir /usr/bin/mkdir \
    --ro-bind /usr/bin/ln /usr/bin/ln \
    --ro-bind /usr/bin/cp /usr/bin/cp \
    --ro-bind /usr/bin/expr /usr/bin/expr \
    --ro-bind /usr/bin/file /usr/bin/file \
    --ro-bind /usr/share/misc/magic.mgc /usr/share/misc/magic.mgc \
    --ro-bind /usr/bin/getconf /usr/bin/getconf \
    --ro-bind /usr/bin/rm /usr/bin/rm \
    --ro-bind /usr/bin/xmessage /usr/bin/xmessage \
    --ro-bind "$HOME/.Xauthority" "$HOME/.Xauthority" \
    --bind "$HOME/.cache/torbrowser" "$HOME/.cache/torbrowser" \
    --bind "$HOME/.torbrowser" "$HOME/.torbrowser" \
    --bind "$HOME/Applications/tor-browser/Browser/" "$HOME/Applications/tor-browser/Browser/" \
    --clearenv \
    --setenv HOME "$HOME" \
    --setenv DISPLAY "$DISPLAY" \
    --setenv XAUTHORITY "$XAUTHORITY" \
    --setenv XDG_RUNTIME_DIR "$XDG_RUNTIME_DIR" \
    $HOME/Applications/tor-browser/Browser/start-tor-browser $@

Assuming that the Tor Browser runs a wayland window, it's capable to run (and display) a web browser over X11/Xorg. But no matter how much you try, this script will not run, and run it with ./sandboxed-tbb-example --verbose will print:

Authorization required, but no authorization protocol specified

Error: cannot open display: :0.0

Now, if you try to run the same script over a Wayland compositor (for example Enlightenment or Sway) it runs fine and prints no error. But in case you want to run TBB over a X11/Xorg session, what should I do? Also I tried adapting the script above to run sway, that even being a Wayland compositor it runs over X11/Xorg sessions as a window. But it printed the same error. I know you can do xhost + local: and it would solve this problem, but is there a better way to achieve this without define stuff through xhost? I think this is possible, because Flatpak sandboxes its applications with Bubblewrap, and it manages to display applications (even if they are displayed over a X11/Xorg session). So it's very possible I'm missing something.

Edit: In this example is assumed that the environment variable XAUTHORITY value is the same as "$HOME/.Xauthority", so this path is already binded at this point.

[rusty-snake]

You do not seem to bind the X11 socket (usually /tmp/.X11-unix). But you do not seem to bind the Wayland socket either.

[8nvHHobXJ1KS]

You do not seem to bind the X11 socket (usually /tmp/.X11-unix). But you do not seem to bind the Wayland socket either.

Doing --bind /tmp/.X11-unix/ /tmp/.X11-unix/ don't solved the problem. It keeps saying Error: cannot open display: :0.0

[smcv]

Additionally, if XAUTHORITY is set to some other location like $XDG_RUNTIME_DIR/Xauthority or $XDG_RUNTIME_DIR/.mutter-Xwaylandauth.A1B2C3 or /tmp/mydm-AbCdEf.Xauthority, you're telling X11 applications to use that file (by propagating the XAUTHORITY environment variable) but you're not actually ensuring that the file is visible inside the sandbox.

In general, writing a simple shell script that invokes bubblewrap is something that can work for a single system most of the time, but it's difficult to make it work for every system all of the time. If you take a look at how Flatpak builds up its bubblewrap command-line, you'll see that it's done programmatically in C code, which results in a command-line about a mile long that specifies everything in exhaustive detail.

In particular, for X11, Flatpak has specific code paths to parse $DISPLAY and pass through the correct socket, and to parse and filter the Xauthority data (avoiding accidentally giving the sandboxed app access to unrelated X11 displays).

[smcv]

Detailed tutorials on how to construct a bubblewrap command-line are out-of-scope for this issue tracker: it seems that bubblewrap is doing what you told it to do, and the problem you are facing is that what you told it to do is not sufficiently complete.

[smcv]

you do not seem to bind the Wayland socket either

I suspect that this is only working in the Wayland case because X11 listens on abstract AF_UNIX sockets which are shared by --share-net, and your Wayland compositor happens to be writing authentication information for Xwayland into either ~/.Xauthority or some other file that is being shared with the sandbox, whereas your X11/Xorg session is writing authentication information to some other place.

Or, your Wayland compositor might be doing the equivalent of xhost +si:localuser:$(id -nu).

I know you can do xhost +local:

Never do this, it's a serious security vulnerability if your machine has users or system uids less privileged than yourself. If you must use ambient authority, xhost +si:localuser:$(id -nu) is less dangerous (but still dangerous, if you want to be able to prevent Flatpak apps from accessing X11).

[8nvHHobXJ1KS]

Additionally, if XAUTHORITY is set to some other location like $XDG_RUNTIME_DIR/Xauthority or $XDG_RUNTIME_DIR/.mutter-Xwaylandauth.A1B2C3 or /tmp/mydm-AbCdEf.Xauthority, you're telling X11 applications to use that file (by propagating the XAUTHORITY environment variable).

You're right. I should clarify that in this case the XAUTHORITY value is ~/.Xauthority. I'll edit my first post to leave this clear.

Detailed tutorials on how to construct a bubblewrap command-line are out-of-scope for this issue tracker

Where should I search for help? Also thanks :)

Never do this, it's a serious security vulnerability if your machine has users or system uids less privileged than yourself. If you must use ambient authority, xhost +si:localuser:$(id -nu) is less dangerous (but still dangerous, if you want to be able to prevent Flatpak apps from accessing X11).

Thank you for clarifying this. You may be surprised how much times I found this answer on Stack Overflow

But in that case. Maybe Wayland requires other files to be mounted to resolve this problem, right?