If you have a client that only supports X Windows, it won’t be able to understand Wayland. You’re best option would be to have a separate system that only has Xorg installed for that use. XWayland allows X apps to run on Wayland, but I don’t know if it can act as a standalone X server.
No, Wayland has a compatibility layer with X (Xwayland), so X clients will work.
I made a connection between the port and the Xwayland socket and this does provide the equivalent functionality. I think Xwayland can probably do this by itself (I just cant seem to find the right option).
Well -listenfd fd only listens on a socket, not the traditional IP port (6000).
I think the only way on Xwayland is using the socat solution.
It’s a little ironic that in disabling port 6000 for remote TCP connections (for vague security reasons) one must use a work around that ends up ignoring xhost protections (since the connection now appears to come from the local user).
Oh boy, I think it’s possible but you need to do some tweaks by adding an override to gdm.
My notes are a little spread out so, so if you give me some time I can piece it together but i can’t test it at the moment.
in /etc/gdm/custom.conf set :
[daemon]
# Uncomment the line below to force the login screen to use Xorg
#WaylandEnable=True
Set the XWAYLAND environment variable export XWAYLAND_SOCKET=tcp
Then restart gdm sudo systemctl restart gdm
Add an override to /usr/lib/systemd/user/gnome-shell-wayland.service.d/override.conf : note: You have to create the directory /usr/lib/systemd/user/gnome-shell-wayland.service.d/ then add the override file there. I have other notes here, but from a different implementation. These are old notes. . .
[Service]
Environment="XWAYLAND_ARGS=-listen tcp"
The restart the user service: systemctl --user restart gnome-shell-wayland.service
Check the connection sudo netstat -plnt | grep 6000
I get an error when I try to restart that service …
# mkdir /usr/lib/systemd/user/gnome-shell-wayland.service.d/
# vi /usr/lib/systemd/user/gnome-shell-wayland.service.d/override.conf
# systemctl --user restart gnome-shell-wayland.service
Failed to restart gnome-shell-wayland.service: Unit gnome-shell-wayland.service not found.
In any case I can brute force Xwayland to use the -listen tcp option (using a script in place of /usr/bin/Xwayland) but it still doesn’t seem to open port 6000.
Yup, Let me try to piece this together. I mentioned earlier, this was from an old implementation and it looks like I missed some parts here. So sorry for that.
sudo mkdir -p /etc/systemd/system/gdm.service.d/
sudo vi /etc/systemd/system/gdm.service.d/override.conf
Perhaps, but yes, you can remove the vulnerability by removing the functionality or keep the functionality available (off by default) and give the user the ability to decide if they can live with the risk in their specific environment. I think the latter is the more reasonable approach.
In other words, “-listen” with a file descriptor is mutually exclusive with “-listen tcp” (for example), so this fix will not help with Wayland compositors that spawn Xwayland with a listen on a socket (like gnome-shell/mutter, weston or wlroots based compositors) - Adding “-listen tcp” to the Xwayland command line from those Wayland compositors will have no effect.
add “-listen tcp” to the end of each line containing “$@”
Example:
#!/usr/bin/sh
#
# Execute Xorg.wrap if it exists otherwise execute Xorg directly.
# This allows distros to put the suid wrapper in a separate package.
basedir="/usr/libexec"
if [ -x "$basedir"/Xorg.wrap ]; then
exec "$basedir"/Xorg.wrap "$@" -listen tcp
else
exec "$basedir"/Xorg "$@" -listen tcp
fi
sudo set-default multi-user
reboot and login
startx
That’s the only way I got it to work as you described
I’ve never attempted this, but the man page (man weston.ini) appears to indicate that you can create a ~/config/weston.ini file containing the following lines to direct Wayland to launch a custom wrapper script instead of Xwayland directly.
[xwayland]
path=/usr/local/bin/Xwayland
I think your custom wrapper could then, conditionally, replace -listenfd <fd> with -listen tcp (you would only do it if the app being launched is your instrument). It is still a hack, but since it avoids modifying /usr/bin/Xwayland directly, I think it will at least survive system updates.
Edit: Reading the paragraph above the earlier quoted one:
Just a final note, when using “-listenfd” (the new option) or “-listen” with a file descriptor (the newly deprecated old way), Xwayland will receive its sockets from the parent process and cannot create its own socket …
So even swapping the -listenfd <fd> with -listen tcp may not work (IIUC, the fd was created before Xwayland is called). If so, you’ll have to go back to your socat workaround. The wrapper script should still be able to scan the parameters to find what fd socat needs to forward to port 6000.
No, I might be misunderstanding the man pages, but it looks like that ~/.config/weston.ini file is a default for all wayland compositors unless the WESTON_CONFIG_FILE env is set.
Also, it looks like Xwayland will listen on multiple file descriptors, so I think you should be able to add another one and forward your port 6000 to that. For example, your /usr/local/bin/Xwayland wrapper might contain the following (untested):
#!/usr/bin/bash
fd=""
if [[ -n $XDG_RUNTIME_DIR ]]; then
MYPORT=6000
MYPIPE="$XDG_RUNTIME_DIR/xwayland-$MYPORT"
socat PIPE:$MYPIPE TCP-LISTEN:$MYPORT,reuseaddr &
sleep 1
if [[ -p $MYPIPE ]]; then
exec {fd}<>"$MYPIPE"
flock -n "$fd" || fd=""
fi
fi
/usr/bin/Ywayland "$@" ${fd:+-listenfd $fd}
Again, untested, but I think something along those lines might work.
Edit: I just tried to test this a bit, but I couldn’t get Wayland to read that ~/.config/weston.ini. Additionally, gnome-shell doesn’t have access to create /run/xwayland-6000. So I moved /usr/bin/Xwayland to /usr/bin/Ywayland and then put the above script at /usr/bin/Xwayland. It seems like it might be working now. It is, at least, listening on the port.
