[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: APIs for persistent remote access and headless/hybrid sessions
From:       Neal Gompa <ngompa13 () gmail ! com>
Date:       2024-02-27 23:22:00
Message-ID: CAEg-Je-5DhOWNVFvTJ5zLpGLmuigGNpGusWn+xHja_jfdTNgcg () mail ! gmail ! com
[Download RAW message or body]

On Tue, Feb 27, 2024 at 2:52 PM Erik Jensen <rkjnsn@google.com> wrote:
>
> I'm on the Chrome Remote Desktop team at Google, and I am working to
> add support for Wayland-based desktop environments. While our initial
> focus will be on getting it to work with GNOME, we'd love the
> functionally to be based on standardized APIs that can be used across
> desktop environments, so I'm reaching out here to see what interest
> there might be on the KDE side.
>
> There's been a bit of discussion[1] on the GNOME Discourse, but to
> summarize, while the existing Portal APIs are great for remote
> assistance use cases where there is a local user to approve the
> session and mirroring the local display(s) makes sense, they are
> lacking functionality needed for the persistent remote access use
> case, where:
>
>  * Connection should be possible immediately after boot.
>  * For security, the session should operate in a headless mode while a
> remote connection is active and the physical seat should remain
> locked.
>  * Virtual monitor layout should be configurable by the remote desktop
> tool to match the client, rather than mirroring the physical layout of
> the host.
>
> GNOME is currently pursuing an approach where the remote access tool
> runs as a system service, and connecting presents a login screen where
> the user can select a session and log in. Some handoff mechanism is
> then used for a process running in the resulting session to take over
> the connection.
>
> The current GNOME implementation is based on unstable, GNOME-specific
> APIs. As far as I understand it, there are three main pieces that
> would need to be standardized for this approach to work in a
> desktop-agnostic fashion:
>
>  * An expanded remote desktop API for the compositor. Unlike the
> Portals API, this API would only be exposed to trusted processes and
> would not require a prompt for each session. Additionally, it would
> provide support for configuring virtual monitor resolutions, layout,
> and DPI, as well as support for accessing the clipboard. Jonas Ådahl
> has been working on creating a standard spec for this functionality, a
> draft of which is available at [2].
>  * An API for requesting a new remote display from the greeter, which
> the remote desktop tool could then attach to using the above API to
> allow the user to log in. This would also provide a method for the
> remote access tool to identify the resulting session.
>  * A protocol by which the greeter can instruct the desktop
> environment to launch in headless mode for remote access, or
> (eventually) transition into/out of headless mode so the user can
> attach to the same session locally or remotely. Desktop Environments
> would presumably signal their support for headless / hybrid sesssions
> via an entry in their respective .desktop file.
>
> Of course, there are other approaches one could take, such as
> expecting the remote desktop tool to handle PAM authentication and
> session creation directly, rather than relying on the system greeter,
> or allowing individual users to set up a remote desktop tool as a user
> service that can only launch sessions on behalf of that user (which
> would require linger and wouldn't work with encrypted home
> directories, but would be more similar to how Chrome Remote Desktop
> currently works).
>
> Is such persistent remote access functionality something KDE would be
> interested in having? Do folks have thoughts on what they'd like to
> see such APIs look like?
>
> Thanks!
>
> [1]: https://discourse.gnome.org/t/persistent-remote-desktop-access-api/19415
> [2]: https://gitlab.freedesktop.org/jadahl/xdg-specs/-/merge_requests/1

(Sorry if you have two, I sent with the wrong address initially...)

I can't speak for everyone in KDE, but I am certainly interested in
seeing this in KDE Plasma.

Last year, I held a talk with David Duncan at Flock discussing the
concept of "Fedora Cloud KDE"[1]. To that end, I've been playing
around with KRdp[2] and other things.

It became very apparent that we have some gaps, and I think they align
quite closely to what you've observed.

What I would like to see is a specification that display managers
could implement to support headless/virtual remote desktop. Then we
don't have to do weird things with PAM, and more importantly, we can
support either protocols that do login directly (RDP) and those that
don't (VNC). This would also likely require extending the
wayland-sessions desktop file format to offer attributes to declare
support for headless login and specific protocols.

I will point out that the pre-authorization problem with portals[3] is
at this point backend-specific (and I think the KDE portal backend
automatically authorizes RemoteDesktop portal for system installed
software). What we need is to push for the frontend-side
(xdg-desktop-portal) to provide a way to consistently apply
pre-authorization policy. It's a major usability problem and will
affect future portals too (such as the accessibility portal being
worked on[4]).

I suspect we might need Plasma Login Manager to exist first[5] before
we can achieve this, though. The kind of integration that GDM and
GNOME Shell have allowed them to pull off what they did there, I'm
not sure how to do it without that integration.


[1]: https://www.youtube.com/watch?v=aPx5tEruG_k
[2]: https://invent.kde.org/plasma/krdp
[3]: https://github.com/flatpak/xdg-desktop-portal/issues/1105
[4]: https://github.com/flatpak/xdg-desktop-portal/issues/1046
[5]: https://invent.kde.org/plasma/plasma-desktop/-/issues/91


-- 
真実はいつも一つ！/ Always, there's only one truth!
[prev in list] [next in list] [prev in thread] [next in thread]