Hacker News Reader

Comment by m4rtink | Hacker News Reader

Wayland by default prevents applications from accessing other application display, input and output, while on X it is basically free for all. Any application can see what any other application is displaying, read it's input & send it it input events.

This might have been fine in the past, but is not really OK any more with efforts to make things more secure (eq. to prevent a malicious application to read you password entry, make screenshots of sensitive data, inject input events to your secure sessions, etc.).

The side effects is that new protocols need to be developed that applications can use to request access to display/input/output of other applications in legitimate cases (such as screen sharing in your case) & not all is in place for that yet.

View on HN

> The side effects is that new protocols need to be developed that applications can use to request access to display/input/output of other applications in legitimate cases (such as screen sharing in your case) & not all is in place for that yet.

This is the main hurdle for most people. I would say that 99% of people agree that the Wayland way makes sense and is he better way of doing things but without the needed access controls it just not ready yet.

Like if Google said "Apps can't access [location|files|whatever] without permission" on Android with no way to grant those permissions.

>Wayland by default prevents applications from accessing other application display, input and output,

So it breaks the entire linux philosophy of using input and output streams to pipe data between different modular applications?

>This might have been fine in the past, but is not really OK any more

Says who? Personally I like my computer being able to access other things on my computer. It kind of makes it more useful that way. The ability for applications on linux to fairly seamlessly work together using a set of standard protocols is one of the primary reasons I use it.

Arguably the end state planned for Wayland in this regard (having access to specific applications provided) is conceptually closer to streams than the current situation with X (one big shared ball of global state).

> So it breaks the entire linux philosophy of using input and output streams to pipe data between different modular applications?

Not really. To use your analogy, the way that X works - every application being able to read the framebuffer of any other - is the equivalent of every application running as root and being able to read and modify any file on the system. When you consider that applications running under Wayland may include e.g. banking details, any app being able to read that is like anything being able to read /etc/shadow.

If your computer is perfectly secure, with no untrusted code running, that's great - and also far more secure than 90% desktop computers out there.

Maybe a stupid question, but can't any program read the memory of other programs from the same user? Can't you attach to it for debugging?

Not necessarily. Newer Linux distros have ptrace disabled on all non-child processes. You can still turn off this protection if you need to.

On many systems, and by default, yes - but the other part of what's going on is that Wayland allows applications to be sandboxed like they couldn't be before, as they can no longer use your X server as a conduit to spawn an unsandboxed shell and run commands. You can, today, run e.g. Firefox in a sandboxed environment and be certain it can't access anything you don't want it to.

AFAIK graphical application disttribution/sandboxing systems such as Flatpak pretty much require this to be avaialable if they ever want to provide reasonably secure sandboxing & might be already making use of this on Wayland systems.

Not really - I should have bean clearer - by input i mean keyboard input and its manipulation.

You can pipe stuff to other executable all you want under Wayland, you might just not easily (eq. user granting permission using the correct protocol) inject keyboard events from on application to another (sey malware masking as a game injecting code in the form of keyboard events into a running terminal emulator or ssh client).

Reply on news.ycombinator.com