XWayland "Rootfull" Changes Merged For Running A Complete Desktop Environment

[oiaohm]

Not securely. You need to have the user join the input group and it leaves all users (and all users' run software) able to read and write the raw inputs. e.g. A pwned browser is able to keylog your terminal input as well as other users' keyboards.

Alternatively you can use a patched openbsd's patched xorg that slightly modifies the x protocol to be secure under non-root execution. However, that's not 100% backwards compatible and often requires patching up gui toolkits and even individual apps...

Of course when that X11 application turns out to be something legacy that you don't source code to as what happens in the Redhat enterprise desktop world you are stuffed with attempting to fix the x11 server in the openbsd way. The Xwayland rootfull for the Redhat enterprise desktop is way better fit. Keep the old behavour of the x11 protocol while having limited what input X11 application can in fact snoop on. So when Xwayland application is out of focus its no longer snooping on input but it can be using the old snooping functions when it does have focus. This is why there is need for xdg-portal or equal global short cut solution the redhat fix does come with its problem of breaking legacy application global shortcuts.

Yes X11 applications basically have coded in keylogger to make global short cuts work. So the difference between a X11 application with a global short cut and a keylogger when it comes down to X11 functions used is basically nothing. This was a problem that was found when xace was first added to X11 server and end up a total failure. The reality here is X11 applications are miss behaving problems. Sandboxing the problem childs is most likely the correct solution.

c117152 the reason why openbsd alteration needs patches to applications is majority how X11 applications have implemented global shortcuts. Cursed devil.

[oiaohm]

No, only users in the input group would be able to do that. Most desktops don't have that many users. On many systems logging out also kills all processes a user has started within a session which leaves little room for shenanigans.

https://www.freedesktop.org/software/systemd/man/loginctl.html

enable-linger is way a person can cause the shenanigans.

Yes logind default to KillUserProcesses when user logs out. But different users running Tmux and other things want their session not terminate when they log out. Yes so they can log off of one machine while something is processing and ssh back in latter to see what its upto. Of course in that Tmux case where you will be coming back over ssh latter the applications losing connection to the local input devices is what you want to happen.

Also you have to think about applications users running getting up to shenanigans. So every application being able to be a keylogger is absolutely not ideal.

binarybanana the business use case is truly different because that use case you can be remoted logged into a machine while the user is using it for maintenance reasons and of course for privacy reasons you don't want as admin to be seeing exactly what the user is doing on the machine. Think about it admin you have started something on a computer repairing in background and you have got out way so person who normally users that machine can get back to doing what they were doing. Of course you want to check back in latter.

These different use cases means the admin wants to be in the input group for local inputs when they are logged in at the keyboard and mouse but they don't want to be in the input group when they are logged into the machine by ssh.

The Xwayland rootfull work here is funded by Redhat for the enterprise desktop use case. The place where countries privacy laws and the like with nasty fines come into play. So correctly controlling what programs and users have access to input in the enterprise desktop case is a requirement so you don't end up having to pay fines. Home users/non enterprise can be more relaxed with this stuff.

The reality the the way X11 manages input is not suitable for enterprise usage in many countries due to allowing keylogging by all applications by design and this causes a privacy law problem in many countries. Xwayland rootfull with a secure wayland compositor under it for running trouble making legacy applications does make sense for the enterprise use case so you tick of the legal requirements on enterprises in many countries.

Would it be good thing for general users to end up with a more secure desktop in time? the answer is absolutely yes.

Xace and the openbsd attempts to fix the X11 keylogger problem also come about because enterprise developers were seeing the legal problems of privacy laws. Yes the encrypted memory of virtual machines we are seeing today is also about privacy law requirements that you don't snoop into areas you are not authorised to by laws.

Fines in enterprise for breaking privacy laws can go into the millions of dollars. This does explain why party like redhat would fund this kind of development. This is not a want by them but they need something that solves particular problems. Yes those particular problems are not solved by a unmodified bare metal X11 server. Yes modified X11 servers by xace or openbsd methods address this need results in being legacy X11 application incompatible.

Big thing here your home user and your enterprise user of computers is very different in the legal requirements they have to work under. What is a nice to have optional feature as a home user to enterprise user can be absolutely need item to avoid having to pay fines. This rootfull stuff is about addressing enterprise user absolute need.

Xwayland Rootfull not just about running x.org X11 server for legacy user as a normal user its about being able todo that while not having the applications proceed to break legal requirements of not snooping on applications where user is inputting sensitive information.

[arQon]

It's always Red Hat who fixes this stuff.

erm, yeah - because Wayland is a Red Hat product.
That's like saying "It's always Microsoft that fixes the bugs in Windows", while implying that somehow Apple is at fault for not contributing to that effort.

Me, I just want this clusterf**k to be *over*. I want my fast, secure display server with a manageable codebase. But apparently we're never going to get that, because the Wayland team is sabotaging both sides of the arrangement by offloading far too much responsibility to "anyone but us", while still demanding sole ownership of the authority to actually fix the protocol to be an adequate replacement for X. So here we are, 15 years later, still waiting. sigh...

[arQon]

Yes X11 applications basically have coded in keylogger to make global short cuts work. So the difference between a X11 application with a global short cut and a keylogger when it comes down to X11 functions used is basically nothing. This was a problem that was found when xace was first added to X11 server and end up a total failure. The reality here is X11 applications are miss behaving problems. Sandboxing the problem childs is most likely the correct solution.

Bullsh*t. That's a copout that completely fails to address the issue by pretending it doesn't exist. The "correct solution" is permissions - something that was obvious even on Day One of Wayland's design.

[dragon321]

Not securely. You need to have the user join the input group and it leaves all users (and all users' run software) able to read and write the raw inputs. e.g. A pwned browser is able to keylog your terminal input as well as other users' keyboards.

Alternatively you can use a patched openbsd's patched xorg that slightly modifies the x protocol to be secure under non-root execution. However, that's not 100% backwards compatible and often requires patching up gui toolkits and even individual apps...

Thank you for explanation.

[oiaohm]

Bullsh*t. That's a copout that completely fails to address the issue by pretending it doesn't exist. The "correct solution" is permissions - something that was obvious even on Day One of Wayland's design.

Day one of Wayland design dbus exists for items needing permission.

https://unix.stackexchange.com/questions/551346/kde-prevent-kglobalaccel5-from-starting

Yes kde and others have attempted to address global shortcuts/hotkeys with a dbus service. Interesting point it been found that not all users need global shortcuts. So not all users need the overhead of monitoring and tracking global shortcuts.

This is the thing a dbus service is a service. Lot of dbus services can be disabled individually.

arQon screen-capture needs permission right so the interface that end up agreed to that with wayland is a xdg-desktop-portal interface that is dbus.. Again this is a feature that not all users need. so for users who don't need screen capture at all they can disable the service since it dbus.

The issue is more of a mess than people think. Wayland protocol was design to composite output as effectively as possible. Not to have a stack of optional parts.

Lot of the missing features of wayland protocol have a clear trend when you look at them. Majority of the features in some use case need to able to be disabled because particular use cases don't want/need that feature.

Remember xace with X11 tried to address the problem by adding a permission system inside the X11 server. This turned into a horrible complex mess because X11 server is monolithic. Monolithic makes sense for compositor itself. Dbus solution is more like a micro kernel/multi process solution..

Remember dbus solution you disable something completely its not running in memory at all but in something like xace you end up with a lot of complex internal code that is possible to incorrectly disable something.

Sometimes the correct answer is not to do something. For legacy applications if there was a existing dbus global shortcut solution that all parties had implemented and agreed on Xwayland could technically be connected to that. X11 inside X11 as in items like XNest could be modified so they don't let keylogging but support global short cuts this way.

arQon lot of the missing features that people complain about Wayland missing are problems that have failed to be addressed correctly under X11 and still need to be addressed correctly under X11. Yes working under X11 due to some insecure/incorrect hack does not mean those features are in fact right.. When it something that need to be fixed for X11 and Wayland that is another reason to use dbus that is shared between the two.

Lot of so called wayland missing features make no sense to be solved in the wayland protocol. Of course getting enough agreement to make a standard for dbus service for that feature has its own problems.

Yes X11 is such a problem child because everything just kept on being added to protocol that really design for graphical output not to be massive permission controlled system. dbus was designed from the ground up to be permission based. The catch is permission system always comes with a performance hit.

So you do need a system that does permissions heavily and system that does permissions lightly. Your graphical drawing path to have low latency wants something that does permissions lightly. Something like setting that my application wants to be informed about X global short cut is something that you need permissions done heavily because you are needing lot more permission control options to cover all the use cases.

Wayland protocol permissions done lightly and dbus permissions done heavily. Remember heavily done permissions like dbus each service can in fact run with different operating system permissions and users can control that.. So each feature dbus provides can have different permissions. Why was X11 server for so long always running as root because it was not a dbus solution it was a light permission solution so permissions to perform all features it does had to be assigned to the X11 server.

This is really like the arguement between monolithic kernel and microkernel. Microkernel allows lot more security control but does come with a performance price.

arQon the old saying round peg in a square hole. Lot of cases X11 protocol and Wayland protocol like it or not is unsuited for. Some of the reason why dbus and dcop before it started originally is this round peg in a square hole of X11 because adding particular featured to the already bloated X11 protocol at the time was not going to work right. Basically attempting to shove everything into wayland protocol is basically attempting to repeat the exact same way X11 protocol got screwed up. Wayland at the start dbus existed. X11 protocol has excuse at the start only x11 protocol existed so they used the method that everything was nail and used the X11 protocol hammer as the solution. Wayland time frame we have hammer and screwdriver solution in Wayland protocol and dbus protocols/services yet many people still are attempting todo a hammer for everything. Yes is people really be as dumb as attempting to use a hammer to drive in a screw with a screwdriver sitting right next to them then wondering why parties who can see the screwdriver think they are being completely stupid. Yes this explains why people put up to wayland protocol a new feature and core people are going that does not make sense here they are in fact seeing dbus and wayland protocol as options.

[arQon]

The issue is more of a mess than people think.

No, after 15 years I'm pretty sure everyone but the fanboys understands exactly how big a mess Wayland is, and why.

The inability to design something competently, and the inability to deliver on that design, is hardly new in this line of work. Claiming that the reason your design failed is because "solving the problems that we used to justify this project in the first place was too hard" though is, as I said, a bullshit copout - especially when those problems are so trivially soluble that they, like the rest of the project, are already 100% covered by decades of common-knowledge prior art.

Amusing though your "performance" excuse screed was, it's rather obviously also not true. If you'd like to read up on the history of "good" privilege management, it realistically starts with VMS, though NT is close enough to give you a decent grounding and probably a lot easier to find. Neither is especially relevant to your position, of course, since it's a strawman in the first place, but you might find it interesting regardless.

[oiaohm]

Amusing though your "performance" excuse screed was, it's rather obviously also not true. If you'd like to read up on the history of "good" privilege management, it realistically starts with VMS, though NT is close enough to give you a decent grounding and probably a lot easier to find. Neither is especially relevant to your position, of course, since it's a strawman in the first place, but you might find it interesting regardless.

VMS and NT did not end up with permission system embedded in the display solution. In fact lot of feature people have attempted to add to the Wayland protocol if you are taking VMS or NT as reference would not be there. VMS that lead NT object system for permissions is closer to dbus. Remember Windows and VMS both have microkernel core in there providing a core general all around IPC with permissions on top. Yes Windows and VMS has another solution for graphics that is not the permission system. So Compositor protocol and generic secure IPC as two different things is the VMS and NT model.

Android Binder and compositor protocol is also this model. Mac OS also has this split. Wayland protocol with dbus protocol under Linux would be doing exactly what all the other operating systems are doing.

Microsoft windows graphical output avoiding the microkernel IPC of the Windows kernel is no mistake. The performance is the reason Microsoft gave for doing this in the first place. Reason why windows is hybrid is moving the graphical services into kernel space so they could output directly without using the Microkernel IPC.

arQon this is part people don't want to get. Wayland protocol if is treated the same and windows graphical output there is lots of things that don't own in there and the reason why Microsoft had them not owning in there was performance reason.

Wayland protocol and dbus protocol do provide the split you see in other operating systems include Windows, VMS, MacOS, Android.

arQon I did spend time with the reactos developers so I understand how windows does this stuff internally. You really need to quote VMS and NT as examples was a huge mistake because the way NT and VMS does things also mandates you split the protocols. You have a IPC with complex permissions and a IPC with simple permissions.

The GDI IPC inside NT has really simple permission system.

https://en.wikipedia.org/wiki/Archit...chitecture.svg Notice the security reference monitor in the design gets interesting that is not connected to the GDI own IPC. Yes Windows policykit equal is the security reference monitor that is connected to the user exposed IPC and other services.

There are two IPC systems inside windows one graphical and one for everything else. Windows does not try to put everything though 1 IPC system. Android has a IPC system for graphical and a IPC system for everything else desktop so two IPC again. This repeats over and over again. Then you get to X11 and Wayland and people try to push everything though a single IPC and wonder with wayland they get told no and with X11 why everything went to hell.

[mangeek]

Weird question but... is it possible to run a fullscreen rootless Xwayland under a wayland session, and if so... does it make sense for everyone to switch to Wayland and for distros & users that want 'legacy X11' to actually just run the entire Window Manager under Xwayland?

Huh. I guess I called it back in February.

[arQon]

You really need to quote VMS and NT as examples was a huge mistake because

it gave you the opportunity to go off and talk about something unrelated instead?

Either you're being deliberately obtuse or you have a fundamental lack of grip on the entire concept of permissions, but regardless of which it is that conversation isn't going to get anywhere.

I'll dumb it down for you: write me the two lines of code a screen reader or keylogger would need if Wayland had been designed competently. Then, and only then, feel free to either (1) write the handful of lines of code the server half would need; or (2) try to justify why Wayland failed to. gl.