Hacker News Reader

Comment by Blikkentrekker | Hacker News Reader

An example would be that X11 has protocols to allow the manipulation of currently selected text. In Wayland no such protocol exists as it's entirely agnostic of how clients handle input and render text.

The result is that on X11 I have a hotkey that automatically normalizes strings to their unicode normal form, something that is not as easily implementable in Wayland, or at all.

A far more basic example is that in order to open new card packs in Hearthstone, to buypass the chore that that involves I can in X11 quite easily send an endless string of space keypreses to an application window without having that window even open or focused. — this is not generally possible in Wayland. Looking it up, a tool ydotool exists to bypass this limitation, which requires root access and directly accesses the input devices to do so.

View on HN

In Wayland, you would use the same method to manipulate the selection. Read it out from the server, do your transformation, then generate fake inputs to rewrite the text. Running ydotool requires elevated access with suid because that's a privileged operation -- if you're running X11 without a sandbox that has a similar drawback as it allows all clients to intercept inputs and send fake inputs to any window.

Fake input under X11 (XTEST) is marked as fake input and any application receiving such events can choose to ignore it. Wine does it, for example.

Right, so that would be a place where something like ydotool would come in handy too because fake inputs coming from there wouldn't be coming from the XTEST device.

Independent of Wayland or X11, why should a user not be able to take inputs for their own window (as in, the owning process is run as the same user)? Why does it require a tool that needs extra privileges (that presumably works by doing it at a lower level)?

That's a genuine question — as in, I'm mostly thinking about Windows and how window message handling works with UAC windows. You can send messages to your own windows all day without needing extra permissions, but not other users' windows. I assume that's what you're referring to with the X11 sandbox; is it reasonable to set up Wayland _without_ such a sandbox?

The short reason is that if the user can do it, so can any application running as the user.

I don't know about you, but I'd prefer my applications not be able to inject and read inputs arbitrarily, though it may be that even stricter sandboxing is needed to make that a reality; Wayland being stricter than X11 is just one step along the way.

> though it may be that even stricter sandboxing is needed to make that a reality; Wayland being stricter than X11 is just one step along the way.

It is not a situation of “it may be”; it is a situation of “it is”.

Right now, it is useless as the security boundary on Unix and any other operating system is fundamentally the user and malicious software that runs as one's user can modify every file and process one owns anyway.

I read one comment a while back by a developer that illustrated the fruitlessness of Wayland by saying that it is essentially a lock on a door, that stands in the middle of room, that one can simply walk around, claiming to add security.

That would be true if someone refused to use any form of sandboxing, however there are multiple sandboxing solutions available that the "door" works in combination with. That is the only real way to make this kind of security work on an ordinary Linux distribution, the approach used by Android where a new user is created for each application is not really feasible.

There are also ways to sandbox X11, it's a bit harder to do, but you do have some options on how you'd like to do things.

Yes, you can run Wayland without a sandbox, but it is being built to work in a case where sandboxes are an option.

Reply on news.ycombinator.com