Red Hat's SPICE 0.14.3 Remote Display System Now Supports Microsoft Windows

[oiaohm]

For multi-user sessions, X11 has XDMCP+SPICE, Windows has RDP (or even RDP+SPICE). What would you use for Wayland?

The following Bugzilla is very unsatisfying:

https://bugzilla.redhat.com/show_bug.cgi?id=1385965

"While I think this is a nice request, but moving to Wayland there will be no more multiple sessions anyways. So closing wontfix."

How do people justify this for an enterprise operating system?

How did they justify this in enterprise systems in the first place with XDMCP.

https://wiki.ubuntu.com/xdmcp

XDMCP does not have proper session to session isolation.

I didn't understand what is a "multi user session", but I'd be a bit surprised if wayland didn't support that one way or another.

Multi user session turns out to be a very bad idea from a security point of view.

https://mstoeckl.com/notes/gsoc/blog.html

Lets take waypipe example instead. Its using ssh remote. You don't have to run anything graphical/complex on the accessed server to display a login dialog instead ssh is starting up the session.

This is what XDMCP is allowing you to run a display manager and show a login in screen that is rendered on the server and historically and horrible wrong allowed you to change the login managers session into the user session and back again without restarting X11 server hello major security flaws. This multi user session stuff is really really bad.

Wayland only really need to be single user session. Of course wayland being a single user session protocol does not mean a server cannot run multi wayland single user sessions at the same time this is secure that you start session when user login details are valid and you end session when user logs out none of the multi user session transferring users between session. Items like ssh, logind.... to take care of the login and create the session. Basically lot cleaner design.

Login manager running under wayland session does not come the user session as X11 did.

Windows RDP also after the login screen in fact changes session this can be a cause of some of RDP security problems.

[Brophen]

Maybe we could get seamless windows then?

[oiaohm]

Maybe we could get seamless windows then?

Waypipe demos seamless windows is possible with wayland across network. In fact wayland isolation nature makes this well and truly dependable. Basically wayland application due to the way wayland is designed is always operating as if it in a seamless window world and if it wants to access like the desktop or anything else that would mess up a seamless function it has to ask the wayland compositor that has the right to say no. So in a lot of ways it simple to make a wayland application seamless than a X11 or Windows one.

There is not really a technical problem with wayland and seamless windows and asking SPICE to have this feature would be sane.

There is still the questions how to handle drag n drop and clipboard in a secure way in the user interface for the remote application. Lot of ways part seamless might be the correct way as in adding a extra boarder to the remote application that has transfer clipboard buttons and allow/disable drag n drop. We have a chance with wayland to redesign the remote links so they are properly sandbox instead of being magically lets let remote application open access to everything.

[starshipeleven]

For multi-user sessions, X11 has XDMCP+SPICE, Windows has RDP (or even RDP+SPICE). What would you use for Wayland?

https://gitlab.freedesktop.org/mstoeckl/waypipe

[kpedersen]

If Waypipe works as you guys say it does then admittedly that is a massive relief!

Is this something that every single compositor needs to implement or part of the protocol? If the latter (and looking through the project it does suggest so) then that is also great to hear.

[starshipeleven]

Is this something that every single compositor needs to implement or part of the protocol?

Are you capable of reading 3 lines in a fucking readme I linked above?
There is also a link in that page to a full explanation with graphics.
Sometimes I have the strong impression that you are just trolling for the sake of it

[oiaohm]

Is this something that every single compositor needs to implement or part of the protocol? If the latter (and looking through the project it does suggest so) then that is also great to hear.

To be correct I understand starshipeleven comment because Waypipe none of the above.

https://mstoeckl.com/notes/gsoc/blog.html

Waypipe does not modify the wayland protocol and does not add anything to the wayland protocol.

Waypipe does not need to be implemented by every single compositor.

Waypipe uses such a simple solution.

1) Server side you have a Waypipe server application pretending to applications on the server that you want to cross network that it is a wayland compositor it turns these communications into something that can go by a ssh socket.
2) Client side you have a Waypipe client application that receives the information from the waypipe server application and passes the requests on to what ever wayland compositor you are using.


kpedersen waypipe is a clean demo that network protocol does not need to be part of the wayland protocol.

The way wayland protocol is design is that compositor has to be local but wayland does not say that that local compositor cannot be just a proxy that makes the requests more suitable to go over the network. Due to the fact the waypipe compositor being at the same end as the application this opens up doing proper opengl/vulkan acceleration on the remote server.

The X11 idea mixing networking and local in the one protocol just end up with a mega mess.

Wayland protocol defines local communication only. Like it or not this is a good thing. Wayland applications basically know where they stand. Wayland compositor for allowing network transversal like Waypipe does is also responsible to have a matching client application and to make the wayland application believe that even that its output and input are crossing the network everything is just normal local operations.

Waypipe compositor due to be a proxy in places just forwards through the features the wayland compositor rendering the desktop is offering to the application.


There is a different way to skin the network client bit than what X11 did. This other way that the wayland world is kind of pushing for is simpler.

[skeevy420]

Multi user session turns out to be a very bad idea from a security point of view.

My current pipe dream would solve that.

The idea is to take something like Fedora CoreOS and build an isolated desktop layer that runs on top of it and everything extra the user needs inside of that isolated layer comes from Flats. Any user that wants to log on would be logging into their isolated environment. For fixed user machines it could be setup so user A gets cores 0 and 1 and the first 4GB of ram, user B gets cores 2 and 3 and the next 4GB, etc.

Eventually we'd get to version 4 or 5 where all you'd need is a server PC to host it and client PCs with bootloaders/home partitions and a GPU and selling that to people is where the money comes from. And for regular people we'd offer you to buy a CoreOS account and you'd get access to an internet provided subscription desktop.

[oiaohm]

My current pipe dream would solve that.

The idea is to take something like Fedora CoreOS and build an isolated desktop layer that runs on top of it and everything extra the user needs inside of that isolated layer comes from Flats. Any user that wants to log on would be logging into their isolated environment. For fixed user machines it could be setup so user A gets cores 0 and 1 and the first 4GB of ram, user B gets cores 2 and 3 and the next 4GB, etc.

Eventually we'd get to version 4 or 5 where all you'd need is a server PC to host it and client PCs with bootloaders/home partitions and a GPU and selling that to people is where the money comes from. And for regular people we'd offer you to buy a CoreOS account and you'd get access to an internet provided subscription desktop.

https://ts.data61.csiro.au/projects/TS/cddc.pml

What is being worked on here is different. You cannot be sure you have security inside silicon. So now window information is transmitted over video out to a compositor Keyboard Mouse Switch that is smartly able to weld the multi screen output of multi windows into 1 screen seamlessly. This is so a end user that need to be logged in as different users only has a single session per machine. The more number of users you need to be logged into at once the more motherboards with cpus you need for isolation.

This design here solves the silicon security problem fairly well with the physical isolation. Where your idea does not.

This cddc is kind of waypipe on another level.