Allow restricting layer-shell and emulated input protocol access to whitelisted applications

[ArrayBolt3]

Right now, labwc seems to more-or-less grant layer-shell and emulated input protocol access to any application that tries to use it. This is convenient, but it breaks Wayland's input isolation goals. Any application can pop open a full-screen layer shell surface, record keystrokes and mouse events that are received by that surface, then destroy the surface and forward the original input event to whatever the intended application was by using an emulated input event. (This assumes focus returns to the appropriate window when the layer shell surface is destroyed, but I believe labwc will do that.) Using this functionality, it's likely possible to write a keylogger (and possibly also a mouse tracker) for labwc and other wlroots-based compositors.

Miriway has a feature where any applications that are going to need to access the layer shell protocol must be listed in a configuration file, where they will be started when the compositor starts. While this mode of operation probably isn't suitable for all labwc users, it might be suitable for some of them, and it would prevent arbitrary applications from sniffing the user's keystrokes and other input data. Maybe this sort of "restricted protocol access" could be added as an optional mode, settable using one of labwc's config files?

[Consolatis]

Labwc has the infrastructure to block specific protocols or only allow a subset of protocols. This infrastructure is currently used for applications using the security-context protocol (flatpak likely being the most known one). The idea was always to additionally expose config options for it as well but its not implemented yet. For reference see #2398.

As for the layershell protocol in particular, you could likely do the exact same thing with any random transparent window. The virtual input protocols are way more relevant in this case.

[ArrayBolt3]

That's a good point about virtual input - even if you can log input, if you can't forward it you're not going to be able to fool the user in most situations (unless they're blindly typing things in).

The security context thing is interesting, I'll look into that. Thanks!

[tokyo4j]

In addition to creating a transparent surface, anyone can launch input_method_v2 client to capture all the keystrokes while a text_input_v3 is focused. This is a mechanism needed for IMEs like fcitx5 or ibus to work.