Most of these things work fine (though with wayland-specific tools, rather than X-specific tools), except:
> (4) global indicator of where my cursor is (xeyes)
AFAIK, no tool allows you to do this. The issue is: clients generally can't snoop on input when they're not in foreground (e.g.: to make key-loggers less trivial).
A privileged client could do this using something like layer-shell. It's a hack, but it should work. Somebody needs to write it tho.
> (5) define global key combinations that launch programs (xbindkeys)
Compositors implement this themselves for the above reason.
> (8) run graphical programs from a headless virtual machine (ssh -X)
I guess this should work with XWayland? Keep in mind, most X applications work via XWayland. This means normal applications; xbindkeys or xeyes won't work since they rely on reading input when other applications are in foreground.
Pretty much any accessibility or automation software suffers here without having to be a root. Wayland makes accessibility impossible is developer with its fragmentation. Want to make tools that work across now Wayland ecosystem good luck with that.
> Pretty much any accessibility or automation software suffers here without having to be a root
Even with root they'll have a harder time; there's a difference between "I can trivially tell the X server to give me details about events and then interact with arbitrary windows in arbitrary ways" vs "by running as root, I can watch raw input events come in from the mouse/keyboard and then try to figure out what they mean".
It’s almost like there are layers to security. You don’t have to be root, but nor should any random npm install script be able to steal keystrokes and send them away. While we are it, linux desktop security just sucks all around.
Thanks for your answers! It's reassuring that most things will still be possible.
Still, xeyes is the favorite program of my kid who is starting to learn linux... I'd have a hard time selling wayland to him.
> to make key-loggers less trivial
Really? Is that a serious reason? Key-loggers are still very much possible because any program can read the memory of all other running programs of the same user. This seems to me like a pointless limitation that creates a lot of unnecessary complexity. But what do I know.
> Really? Is that a serious reason? Key-loggers are still very much possible because any program can read the memory of all other running programs of the same user.
That's not true. Reading other processes memory requires root even for processes of the same user.
I was going to reply in an impulsive manner (saying, derisively "so how does strace work, then? and why can you attach gdb to already running processes?").
But it turns out that you are right! Well, at least in modern ubuntu/fedora desktop installs, a few years ago they disabled the ptrace(2) system call. ("The maniacs! They did it!", I'm tempted to cry in anger.) You can still read children processes, but unless you change the yama defaults in the kernel, ptrace(2) no longer works for processes that are not children.
I didn't notice because I surely have changed this default in my old laptop because I use ptrace daily. But you are right that modern linuxes are likely thus crippled.
Still, it seems that an attack model based on defending against a rogue user process is quite doomed. Can't this process change the init files of other programs that will run, even if they aren't its children?
> Still, it seems that an attack model based on defending against a rogue user process is quite doomed. Can't this process change the init files of other programs that will run, even if they aren't its children?
No, they often can't. Things like Flatpak make it so apps have no unnecessary access to the filesystem.
Fortunately, things like snap and flatpak are still fringe projects with no realistic perspectives for a widespread adoption. Which would be ridiculous, anyway: why would you want all the programs in /usr/bin to be isolated "apps"?
> (4) global indicator of where my cursor is (xeyes)
AFAIK, no tool allows you to do this. The issue is: clients generally can't snoop on input when they're not in foreground (e.g.: to make key-loggers less trivial).
A privileged client could do this using something like layer-shell. It's a hack, but it should work. Somebody needs to write it tho.
> (5) define global key combinations that launch programs (xbindkeys)
Compositors implement this themselves for the above reason.
> (8) run graphical programs from a headless virtual machine (ssh -X)
I guess this should work with XWayland? Keep in mind, most X applications work via XWayland. This means normal applications; xbindkeys or xeyes won't work since they rely on reading input when other applications are in foreground.