Multi seat with nested servers?

Pekka Paalanen ppaalanen at gmail.com
Mon Dec 12 11:32:27 UTC 2022


On Fri, 09 Dec 2022 10:09:02 -0500
Phillip Susi <phill at thesusis.net> wrote:

> Pekka Paalanen <ppaalanen at gmail.com> writes:
> 
> > There are two different approaches:
> > - nested compositor presents to the root compositor which presents to KMS
> > - nested compositor uses KMS leasing offered by the root compositor,
> >   and presents to KMS directly
> >
> > In the leasing case, the root compositor may not need to be even a
> > Wayland server nor a compositor. It could be a system daemon like
> > seatd or logind, if they offered the API for it.  
> 
> How does this leasing work?  Does it lease the entire GPU or can it
> lease only one display?  I would imagine it would be the entire GPU, in
> which case you couldn't lease it to both servers.

Leasing works by delegating a chosen set of KMS resources to a new DRM
device fd, which then has access to *only* those resources. KMS
resources are: connectors, CRTCs, planes. Not GPUs at all. GPUs are
already shared through render nodes and do not need leasing or
partitioning like this.

See https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#drm-display-resource-leasing

> > In the root compositor case, the root server would indeed need to proxy
> > the input as well. That would maintain security.  
> 
> Why do you say that?

Because session compositors (the nested compositors here) should never
be allowed to open input devices themselves. The session compositor
runs as the end user account, and if the end user account can open
input devices, so can all other programs the end user runs (not
sandboxed). Measures need to be taken to disallow unintended programs
from getting input events, otherwise they may become key-loggers.

> > OTOH, in the leasing case, if the lease daemon is also leasing out
> > input devices (like seatd and logind already do today), input would not
> > need to be proxied.  
> 
> What is this leasing you speak of?  AFAIUI, logind just maintains a
> database of what input devices belong to what seats so that the display
> server can query it and find out which devices it should open.

Logind (and seatd) also opens all input devices on behalf of a display
server, be that a Wayland compositor or Xorg. A display server
normally lacks the permissions to open any input device. Otherwise the
daemon cannot enforce security, seat-assignments and exclusive access.
The daemon can also forcefully revoke input devices from a display
server.

Logind knows which seat the display server is supposed to be running
on, and agrees to open only input devices of that seat, and only when
that particular display server is foreground. (Several sessions can
share a seat, but only one can be foreground at a time, like
VT-switching but not tied to VTs and not extremely fragile like VT
handling.)


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20221212/becc0207/attachment.sig>


More information about the wayland-devel mailing list