So.. Lets talk about Wayland (long term feature request and discussion)

[tommydrum]

As we know, Wayland is not network compliant, and leaves most of it's rendering to it's clients. Xorgxrdp's method on adding in a module to xorg provide a virtual display won't work with Wayland, because wayland doesn't have a rendering api.

From https://wayland.freedesktop.org/faq.html

Is Wayland network transparent / does it support remote rendering?
No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.

So, wayland clients like Weston and Mutter now carry the Rendering API.

With that said, if we were to approach Wayland, would it be better to provide a module for Weston/Mutter (sounds easier), or be a wayland client ourselves and provide a common API for other wayland clients (depending on what it entails to be a wayland client, could be quite a lot of work).

I don't know if being a wayland client would require us to have our own render, or if there is a common render wayland client existing that is (or could be) implemented by others.

I went down a rabbit hole I'm not entirely sure is the correct one for this conversation.. but could at least start one.

[moobyfr]

IIRC, there is already some code in weston for a RDP backend:
https://www.phoronix.com/scan.php?page=news_item&px=Weston-RDP-GL-Accel

[tommydrum]

That's pretty great. I could dig into it to try implementing it in xrdp, but this is around 2 months old. It's probably wise to let it mature out of devel. As a path forward, because Weston was nice enough to start the precedent on implementing an rdp compositor, we can ask the Mutter team to follow suit, and that gives us a few desktop environments for virtually free.

[ohault]

This issue is becoming pretty important.

[rstanuwijaya]

Seems like will require a lot of work to make this happens. Most likely it will need to support a different backend than current xorgxrdp to connect a headless wayland session to the xrdp server. Even more, a separate backend might be needed for each DE (gnome, kde, and wlroots).

Nevertheless, considering many distros are deprecating Xorg, I'm really looking forward for the devs to support this feature in the future.

[matt335672]

I'll add some of my thoughts here, having been prompted by @HubKing in #2840.

I'm far from an expert in this area. I'd appreciate anything below which requires correction to be pointed out. I'd rather provoke a discussion though rather than saying nothing at this point.

Main points:-

• We're not the only project which needs an architectural solution for this - see this discussion on TigerVNC.
• Rather than choosing to use the reference compositor called Weston, desktops seem to be picking their own (GNOME : Mutter, KDE : kwin). So there are many compositors out there. It's not clear to me how much compositors can be interchanged, or whether nested compositors are possible (see the TigerVNC thread linked above).
• According to the Arch Wiki, most compositors require KMS.
• There's an interesting Linux kernel module called VKMS which might allow a virtual display to be created which could run a compositor.

By this stage, there are a lot of warning bells ringing:-

1. It seems unlikely that remote desktop use-case has been considered in the Wayland design (again, see the TigerVNC thread). There are significant implications for performance here if not running on the machine console, maybe by using VKMS or nesting compositors.
2. This is all mostly Linux-specific at present. xrdp works on other platforms too, notably FreeBSD. On platforms without systemd, xrdp actually works better as multiple sessions per user are available.

In other words, it's a bit of a mess at the moment.

It's not clear (to me at least) how this will pan out. My own thinking is to keep an eye out on what the TigerVNC crowd are up to. Red Hat are, or used to be a sponsor of TigerVNC, so if there's any interest in the virtual desktop market, I'd expect TigerVNC to get a steer before we could.

[Nexarian]

I agree with everything @matt335672 said. I think @jsorg71 has ideas about how to get Wayland working with XRDP. I wanted to link the two actual commits where GNOME dropping X11 support is being discussed:

• https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98
• https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/99

Also do note that, like all media, tech media picks things that are most likely to be sensationalized. The fear we all have is that all Linux distros drop X11, and then XRDP is utterly dead. Let's put that part of our fear aside and recognize that because remote desktop is popular and useful, it is unlikely we'll be left out in the cold like that. That being said, the problems with remote desktop are sufficiently surfaced as a blocker for "everyone move to Wayland" which is good, but it doesn't guarantee that at some point the powers-that-be will decide "Everything works well EXCEPT remote desktop, and the pros of moving outweigh the cons, we can't support everyone." I've seen big organizations make decisions like that, so we need to be prepared. Note that the comments on some of these merges have been silenced because it was so noisy, so there is sufficient reason to believe that XRDP and Gnome and X11 will be around for many years to come.

One suggestion I have is to work on helping https://gitlab.gnome.org/pnowack and https://gitlab.gnome.org/jadahl with the technologies behind gnome-remote-desktop, and then we can share each other's code. My AVC444 and YAMI work is along this path (and is generically sharable between XRDP and GRD), but it's a tiny tiny piece of that puzzle.

The big action-item to try to see if we can throw out weight behind is this one: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/90, if anyone reading this has free cycles and/or is looking for a good and hard project to get into open source, this is definitely one! That is how I myself got into this. I picked something I wanted, and banged my head against the wall until I made a useful contribution.

However, that will only "fix" gnome, and there are many others. Having each window manager have it's own RDP compositor would be a maintenance nightmare, and leave lots of lesser-known window managers like i3 or Cinnamon in the dust. The hope would either be that getting this working on Gnome provides a footprint/feedback-loop for other window managers to do this or it creates pressure for an all-Wayland solution.

At this point I generally agree with Matt that provoking a discussion and a paper trail is critical here.

[jsorg71]

I'd have to agree with Tiger VNC guys. Wayland is not designed for remote desktop, multi session, or non GPU use cases. It's a composite only display system. It's designed by the xorg guys to simplify.
I think we can support this use case but you will have to use a GPU or more CPU power it use it with the same experience quality. MS even turns of composite desktop with the multiple session terminal servers but Wayland has no non composite options.
Nexarian, me, and others have been working on GPU support in xrdp which can be used here.

todo, unknowns here

1. clipboard in chansrv would need to change.
2. RAIL in chansrv, how would that even work? Since wayland is build into the window manager, is this possible?
3. sesman should only start KDE or Gnome, or whatever window manger that has wayland support. no xorg or waitforx.
4. wup would be used instead of xup. I think wup would just use pipewire to get a desktop stream.

Core xrdp is not dependent on X11 even though the x in the name. The x was meant to mean whatever. The backend, Xorg with xorgxrdp and chansrv are display dependent so they would need to change.

If Wayland ever gets there, lets support it. Can we even run native Firefox, Chrome and OpenOffice on Wayland without XWayland? It is taking forever....

I think the Xorg use case will remain for a very long time. The 50+ users on one server, traditional terminal server, legacy apps.

[nielsdg]

Hi, someone pointed out this thread to me to see if I can shed some light here about what's possible in the Wayland ecosystem currently and what is in progress. (for full disclosure, I work at the RHEL GPU team, which has done some big efforts over the last years in preparing the move to Wayland)

For a lot of the things that xrdp needs to properly function on a Wayland system, these are already available today in the broader Wayland ecosystem and that are agnostic of the compositor/DE in use. Most of these are actually exposed to applications through portals, a set of cross-desktop D-Bus interfaces which can also be used within containerized apps such as flatpak, if they want to.

Most of all, a project like xrdp would implement its remote desktop logic with 2 of these portals:

• the RemoteDesktop portal. This portal allows you to inject events like mouse events, keyboard presses etc
• the ScreenCast portal. This portal allows you to read the contents of the desktop (or a specific window). These textures will be passed on to you through pipewire which you can then send over the network with RDP/VNC

You can find an example of how to use these portals in Python here: xdp-remote-desktop.py (note that you might need some specific packages installed for this). It should show a window which screencasts your current desktop and presses the <Super> button.

Now, there is one final part that is still WIP and which ties into the aforementioned gnome-remote-desktop issue: the ability to start a headless session. GNOME is currently experimenting already with an implementation for this (see for example gdm!180), after which we can hopefully figure out what the API should look like, and would allow us to propose a common API as well.

So while Wayland isn't totally ready yet; it should be possible already to start experimenting with some of these things while we're working things out further, especially on starting a session.

Feel free to let me know if you have any questions or remarks! :-)

[matt335672]

Thanks very much for adding that @nielsdg. It's very interesting, particularly as it gives us a way to proceed which is compositor/DE-agnostic.

[Nexarian]

I've been chatting with @pnowack in the FreeRDP gitter and he had a few tips for us that I'll capture here for future reference:

• Add Headless service for GRD
• Add graphical remote login for GRD

The Remote Desktop Portal API exists since half a decade. You just need to use it. Several parts from it were inspired or copied from GNOMEs private API, that g-r-d uses. This for example applies to the whole clipboard part, virtual monitors, and the lock keys. So, it is kinda true, that GNOME defines the direction here.
However, there is some effort to standardize the efforts eventually:

https://gitlab.freedesktop.org/jadahl/xdg-specs/-/merge_requests/1

[tidux]

I believe Plasma and wlroots are also working on RDP support.

[nikimagic]

Да, в КДЕ делают свой сервер

https://planet.kde.org/arjen-hiemstra-2023-08-08-remote-desktop-using-the-rdp-protocol-for-plasma-wayland/

https://github.com/KDE/krdp

[JoeSalmeri]

@matt335672

Thanks very much for adding that @nielsdg. It's very interesting, particularly as it gives us a way to proceed which is
compositor/DE-agnostic.

Just curious how this is progressing ?

I've read most of the links above. Looks like Gnome-Remote-Desktop has added headless RDP support which will be available with Gnome 46.

I use KDE Plasma which as we know is defaulting to Wayland with Plasma 6.

Currently I use xrdp for my terminal server and it works great !

Is there an ETA as to when we might see a test version ?

Thanks to all the contributors working on this

[nikimagic]

Да, xrdp великолепен!
И я конечно же, хочу использовать wrdp!!!

))) помогу с тестами, если будет версия wayland

[matt335672]

No, we don't have an ETA for this yet.

We've not yet done the gap analysis of what xrdp currently provides over X, and what will be initially possible with Wayland. Bear in mind also that GNOME now only supports one session per user, and if GRD does provide a headless session and remote login support, there's not a lot of extra value that xrdp could provide anyway.

[nikimagic]

Ценность xrdp, в том, что мы ставим сервер, виндовс подобный. Например kde.
И даем доступ на сервер многим пользователям, с уникальными учетными записями. Обычно, не нужен доступ двух или трех сеансов (людей) под одной учетной записью. Но, иногда, актуальна трансляция экрана другому человеку. А иногда актуален и одновременный сеанс двух человек сразу.

Если wrdp, будет обеспечивать уникальный сеанс, буфер обмена, и обмен файлами через буфер обмена, это уже 90% всех желаний.

Линуксов много. Я привык к убунте, но посматриваю и на федору.
Отказываться от xrdp не могу. Альтернативы для меня не существует.
Wrdp актуален, с учетом массового перехода всех на wayland

---

Google translate
The value of xrdp is that we put a server like Windows. For example, kde. And we give access to the server to many users with unique accounts. Usually, you don't need access to two or three sessions (people) under the same account. But, sometimes, it is relevant to broadcast the screen to another person. And sometimes a simultaneous session of two people at once is relevant. If wrdp provides a unique session, clipboard, and file sharing via clipboard, that's already 90% of all desires. There are a lot of Linuxes. I'm used to ubuntuta, but I'm also looking at fedora. I can't give up on xrdp. There is no alternative for me. Wrdp is relevant, given the mass transition of everyone to wayland

[matt335672]

Thanks @nikimagic

You make a good point, so I've taken the liberty of pasting a Google translation of your post into English for non-Russian speakers.

The implementation of the clipboard is provided via chansrv and is currently one of those things that depends heavily on X11. I haven't yet looked to see how the Wayland interfaces which would be available to us would let us access that.

[nikimagic]

https://wayland-book.com/

https://github.com/bugaevc/wl-clipboard

[JoeSalmeri]

@matt335672

Thank you for the update. From my reading Gnome 46 is supposed to have the headless support and remote login and looking at links and checkin's it appears that is the case.

I use KDE, so while that solution would work for Gnome users, I suspect that it will not work for KDE users or other desktop environments ( but I could be wrong ).

Assuming that GRD requires GNome then it would seem that everyone else that doesn't want to switch to Gnome will be looking for a solution too.

Any thoughts on that ?

For my use cases, I have multiple simultaneous remote desktop sessions each with a different user logged in ( like xrdp provides and like Windows Terminal services provide ) at the same time that I am often also logged in on the server console.

Many websites seem to intermix Remote Desktop with Remote Screen sharing which may have overlap in technology but provide very different function ( as you are well aware ). I have read numerous articles which present Remote Screen Sharing as if it is Remote desktop which is extremely frustrating when you are trying to find information on the topic.

I use openSUSE Tumbleweed which appears is going to push out plasma 6 this week.

2 of my test machines ( one arch, the other EndeavourOS ) both now have plasma 6 and default to Wayland on login but after accepting the login credentials the screen just goes black ( with the cursor ) and no indication of any issues.

Fortunately the login screen still allows you to switch to x11 which works fine.

A 3rd test machine has plasma 6 and is running the latest Neon build and there Wayland login works fine so clearly something is up with the arch based distros which is causing the Wayland login issue but it certainly does not instill confidence in Wayland.

Sure hope that X11 is not completely killed off / dropped before we have full RDP functionality with Wayland.

[matt335672]

@nikimagic also made the point that a valid use case for xrdp is multiple users on a single server. This isn't supported by GRD directly.

Taking a wider view, here's a summary of the current industry situation as I see it:-

• There's no doubt that Xorg is going away. In theory there's a possibility that some or all of it could be maintained by another project, but there's no evidence that this will happen. There's plenty of grumbling about this, but no-one's prepared to step in with actual money to support any of Xorg, at least as far as I can see.
• The interfaces proposed by @nielsdg in this comment are the way we probably need to go for a desktop-agnostic solution. That's fine provided they gain widescale adoption. At the moment, there's no real evidence this will happen any time soon e.g. searching for "org.freedesktop.portal.ScreenCast" and "KDE" doesn't produce any useful links.
• KDE are going their own way with KRdp. This doesn't seem to be using the interfaces in 1. above, possibly for reasons of performance - they're H.264 only. Also the set of use-cases supported look more like GRD user-cases than a terminal server use-case.
• XFCE haven't even considered Wayland remote desktop use-cases yet, let alone Wayland terminal server use-cases.

It's hard to see a sensible way forward at the moment. Currently we seem to be moving towards a world where we would need to provide desktop-specific back-ends for this project, or pick one and stick with it.

This is all just my opinion and doesn't necessarily reflect the view of any other project members. If anyone wants to refute or challenge any of the above, please do!

[nielsdg]

KDE are going their own way with KRdp. This doesn't seem to be using the interfaces in 1. above, possibly for reasons of performance - they're H.264 only.

I don't think that is correct. The blog post you link to specifically mentions that Krdp uses the RemoteDesktop portal. The H264 encoding is not something that is done by that portal, so it's somewhat irrelevant: what you get from the portal is a Pipewire FD which allows you to get the video stream of your desktop. After that it's up to the service whether to encode that to H.264, VP9 or whatever codec or not encoded at all.

Currently we seem to be moving towards a world where we would need to provide desktop-specific back-ends for this project, or pick one and stick with it.

There's some very early work ongoing to make a cross-DE spec for the actual remote login itself (see https://gitlab.freedesktop.org/jadahl/xdg-specs/-/merge_requests/1) but that will still take a while to materialize probably.

[matt335672]

@nielsdg - thanks for the correction and clarification. That's useful.

[JoeSalmeri]

@nikimagic also made the point that a valid use case for xrdp is multiple users on a single server.
This isn't supported by GRD directly.

I made the point about multi-user Remote desktop on a single server.

It is critical for my environment.

I am a little surprised by the lack of thought in Wayland regarding this.

Linux is a great multi-user environment, whether someone wants to use RDP or VNC or X11 forwarding and yet the need seems to have fallen by the wayside.

I just built a massive new server specifically for terminal services.

Regarding your GRD comment, one of the links about GRD in this thread talked about having a user session service which in my understanding would allow multiple users at the same time to use remote desktop like we have with xrdp today.

Here's the link

https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/215

The headless support seems to be what will make it possible unless I have misunderstood.

[matt335672]

The headless support is a start.

Underneath everything, it's providing what Xvnc and other variants have provided for years - a virtual canvas on which the user can run applications / a desktop / whatever. The link you provide gives a way to start a GNOME session and the canvas in one go.

[JoeSalmeri]

@matt335672

I don't understand why you said the headless support is a start.

From what I've read it seems that once the headless support was added a remote user could initiate an RDP session and get the GUI login and login and that it was not limited to a single user since the service would spawn for each connection.

Are you saying that is not correct ? I'm not doubting you, just trying to figure out if I have misinterpreted what I read...

[nikimagic]

Of course, it should be understood that our scenario is 80 users on a remote server. Each user is completely independent of the others. Every user should be safe.

Everyone has a personal computer, completely different equipment, screen resolution, mostly laptops with Windows, but there are also home dual-monitor computers.
And all this diverse bunch of hardware, via rdp, connects to the linux server. This is the most important use case, with a copy paste between Linux and Windows, with file exchange between Linux and Windows - copy paste, in both directions.
In such a scenario, you can neglect the transfer of sound from Linux to Windows. But, screen control, and copy-paste buffers and files in both directions, this is a mandatory feature.

Yes, there are other scenarios. When, for example, a home LAN, and a user, he is also an administrator, connects via rdp to his own computer. But even here, there may be such users by the number of family members. Or there is only one person, but he runs several accounts at the same time, and uses different software there, and rdp control.

The world has changed. Remote work has come to the fore. And the appearance of such family servers is becoming commonplace. If we talk about small businesses, then there is either one server for all, or several servers for several teams.

Of course, IT specialists are at the forefront. But, even ordinary users, far from it, go this way. Linux as a whole has changed fantastically over the past 5 years. For the first time in its history, Linux has become simple and usable for ordinary people. Classic user case, chrome browser, telegram chatbox, vlc video, analog word excel, steam games. All this, just 10 years ago, was hard to imagine without Windows.

And now, remote use is becoming a necessity. I am sure that remote use, and even the transfer of remote control, such as a phone, will become a standard feature for all gadgets. Of course, there are very serious security issues here. But whether we like it or not, the world is moving in this direction very, very fast.

[nielsdg]

I am a little surprised by the lack of thought in Wayland regarding this.

Just a quick comment on this: in Wayland, like any other open source project, somebody still needs to do the work. There's always a massive backlog and so few contributors though. So this "lack of thought" is more of a "people didn't get to it yet" as they either weren't interested or had other work on their places.

In the end, the best way to move things forward, is to help by contributing to the project. Especially if people here mention that they're building a business on top of it ;-)

In any case, I agree with the fact that headless support is a start. Even if multi-user wouldn't be supported, having the code path for an RDP session that can handle a Pipewire stream is already half of the work being done, so it would be a good first step that shouldn't be blocked on anything (and should work on anything that supports the RemoteDesktop potal).

[matt335672]

@JoeSalmeri - my apologies. I'm not being clear. I think you're (sensibly) coming at this from the top-down and because I've just been involved with the GFX implementation I'm thinking about this more from the bottom-up.

From what I've read it seems that once the headless support was added a remote user could initiate an RDP session and get the GUI login and login and that it was not limited to a single user since the service would spawn for each connection.

I absolutely agree with your statement above. I was thinking more about what happens next.

With xrdp, when we start (or reconnect to) a session, we're able to size it (or resize it) fairly easily. A common use-case is a user using a particular monitor configuration in the office, and then coming home and reconnecting to the session over a VPN using a totally different monitor configuration. On the whole this just works. The interfaces we use to accomplish this are well-defined and pretty stable.

Our users are used to this functionality, and (to my mind at least) it's something we would need to provide as part of an initial implementation.

I currently have no idea how we will accomplish this with Wayland. I'll be the first to admit I need to do more research into this area, but I've failed to find a desktop-agnostic interface which would allow us to accomplish this.

That's the bad news, The good news is this is the only major piece of the puzzle which appears to be missing. The clipboard will require reimplementing, but this is well documented. Other features like drive redirection should work with no changes.

The outline design I have in my head at the moment is as follows:-

1. User connects to xrdp as usual and authenticates
2. xrdp asks sesman to start a session
3. For Wayland, sesman runs a single (configurable) command to start the session. So, for GNOME we can just activate a systemd unit. I can see this being a common option. Later, there may be a D-Bus API to do this.
4. chansrv is started, either by sesman or as part of the systemd unit (TBD)
5. xrdp connects to session (using RemoteDesktop/ScreenCast portal(s)) and chansrv. There are questions here around security and permissions. Currently xrdp runs as either root or a captive user, but it may need to run as the target user instead.
6. xrdp asks session (via chansrv?) to adopt the monitor config

So it's not vastly different from what we do at present. I'm omitting a lot of detail, but I don't think a brain-dump from me would be that useful at this point.

As always, feel free to ask questions or criticise any of the above.

[nielsdg]

FWIW, I think that matches from my (limited) knowledge on how gnome-remote-desktop is implemented and how some other third-party service was doing it

[JoeSalmeri]

@matt335672

@JoeSalmeri - my apologies. I'm not being clear. I think you're (sensibly) coming at this from the top-down and
because I've just been involved with the GFX implementation I'm thinking about this more from the bottom-up.

No worries, you are right I am definitely coming at from the top down and the end user perspective.

I absolutely agree with your statement above. I was thinking more about what happens next.
With xrdp, when we start (or reconnect to) a session, we're able to size it (or resize it) fairly easily. A common use-case > is a user using a particular monitor configuration in the office, and then coming home and reconnecting to the
session over a VPN using a totally different monitor configuration. On the whole this just works. The interfaces we use > to accomplish this are well-defined and pretty stable.

Yes, that would apply to some of my RDP users. For myself, most of my RDP sessions are from the same computer where I have dual monitors setup.

I currently have no idea how we will accomplish this with Wayland. I'll be the first to admit I need to do more research > into this area, but I've failed to find a desktop-agnostic interface which would allow us to accomplish this.

While I have lots of development experience ( 30+ years ), I don't have any experience in this area otherwise I would consider jumping in to help.

That's the bad news, The good news is this is the only major piece of the puzzle which appears to be missing. The
clipboard will require reimplementing, but this is well documented. Other features like drive redirection should work
with no changes.

Well that is definitely good news. Clipboard sharing is definitely nice but not a show stopper for me. We don't use drive redirection. Instead the login scripts on Windows or Linux clients map or mount the network shares that are needed.

The outline design I have in my head at the moment is as follows:-

Thank you for sharing your detailed thoughts I appreciate it !

openSUSE Tumbleweed switched to plasma 6 on 03/11/2024 but X11 is still available so for now I'll just use X11.

Also, VMWare player vm's seem to have a problem logging in via Wayland. Login screen displays but if you select Wayland then all you get is the cursor and blank/black screen after that. Happens on VMs I have for Tumbleweed, Arch, and EndeavourOS so far. Have not updated other test systems to plasma 6 yet.

[JoeSalmeri]

@nielsdg

Just a quick comment on this: in Wayland, like any other open source project, somebody still needs to do the work. >There's always a massive backlog and so few contributors though. So this "lack of thought" is more of a "people didn't >get to it yet" as they either weren't interested or had other work on their places.

Understood, just seems like an area that many would consider one of the more critical things to have working, especially when you consider how much remote work has picked up since COVID.

In the end, the best way to move things forward, is to help by contributing to the project. Especially if people here > >mention that they're building a business on top of it ;-)

Understood. FYI, I have 30+ years of development experience but not in any areas that would be helpful here, otherwise I would gladly jump in.

In any case, I agree with the fact that headless support is a start. Even if multi-user wouldn't be supported, having the >code path for an RDP session that can handle a Pipewire stream is already half of the work being done, so it would be a >good first step that shouldn't be blocked on anything (and should work on anything that supports the RemoteDesktop >potal).

For me the multi-user support is a requirement, otherwise a single server machine could only be used by one person.

It sounds like the GNome people have this working on Gnome 46 but I haven't tested it yet and I would prefer to stay with KDE plasma.

[JoeSalmeri]

@nikimagic

In such a scenario, you can neglect the transfer of sound from Linux to Windows. But, screen control, and copy-paste buffers and files in both directions, this is a mandatory feature.

You can easily get around the transferring files need by simply mapping drives between the 2 or mapping a shared drive they both have access too. I prefer doing that I believe it performs much faster too.

Yes, there are other scenarios. When, for example, a home LAN, and a user, he is also an administrator, connects via rdp to his own computer. But even here, there may be such users by the number of family members. Or there is only one person, but he runs several accounts at the same time, and uses different software there, and rdp control.

Yes, I use RDP to manage computers in the household and those same computers RDP into the Linux server for many of their tasks.

And now, remote use is becoming a necessity.

I completely agree.

[tidux]

5. xrdp connects to session (using RemoteDesktop/ScreenCast portal(s)) and chansrv. There are questions here around security and permissions. Currently xrdp runs as either root or a captive user, but it may need to run as the target user instead.

Maybe xrdp could do something like what OpenSSH does where the main daemon runs as root but each user's session sshd processes run as themself?

[matt335672]

@tidux - we're not quite where OpenSSH is.

The model we're moving to is the main xrdp listening process is non-privileged and runs in a captive user account (see #2974). sesman starts new user sessions and so needs to run as root.

For OpenSSH, both of these functions are combined in a single process running as root.

The workflow for us to run xrdp as the target user rather than the captive user would be:-

1. Client connects to xrdp
2. xrdp forks and runs the login process to gather user details. This uses the RDP connection.
3. Following a successful login, the client socket connection would need to be passed to sesman. This would start the session, and also re-run xrdp as the target user, passing the client socket to the new xrdp. Crucially the new process would be missing some information about the connection which the original login process had discovered. We can probably work around that somehow.

So it's quite a bit more complicated. Is it more secure?

Arguments in favour:-

1. Each xrdp user process does not have access to user processes held by other users

Arguments against:-

1. It's more complex
2. Attacks not possible in the existing model are possible in the new. As an example, in the old model the user can't send signals to the xrdp process. This should be safe enough, but we haven't tested it.

Thoughts or arguments are welcome.