Hacker News new | past | comments | ask | show | jobs | submit login

>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.




> 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?


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 necessarily. Newer Linux distros have ptrace disabled on all non-child processes. You can still turn off this protection if you need to.


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).


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).




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: