RFC: libei - emulated input in Wayland compositors

[Jonas Ådahl]

On Fri, Jul 31, 2020 at 11:00:53AM +0300, Vlad Zahorodnii wrote:
> Howdy,
> 
> On 7/31/20 8:13 AM, Peter Hutterer wrote:
> > I've been working on a new approach for allowing emulated input devices in
> > Wayland. Or in short - how can we make xdotool and synergy work? And
> > eventually replace them.
> 
> ++, it would be nice to have something that is supported by all major
> compositors + working synergy on Wayland. :-)
> 
> > The proposal I have is a library for Emulated Input, in short libei.
> >   https://gitlab.freedesktop.org/whot/libei/
> > 
> > libei has two parts, the client side (libei) for applications and
> > a server side (libeis) for the compositor. The two libraries communicate
> > with each other (how? doesn't matter, it's an implementation detail) to
> > negotiate input devices.
> > 
> > The process is roughly:
> > - the libei client connects and says "I am org.freedesktop.SomeApplication
> >   and I want a pointer and a keyboard device"
> > - the libeis server says "ok, you can have a pointer device and a keyboard
> >   device"
> > - the libei client says 'move the pointer by 1/1', etc. and the server does
> >   just that. or not, depending on context.
> > 
> > There are more details, see the README in the repo and the libei.h and
> > libeis.h header files that describe the API.
> > 
> > The sticking point here is: emulated input comes via a separate channel.
> > The server a) knows it's emulated input, b) knows who it is coming from and
> > c) has complete control over the input.
> > 
> > a) is interesting because you can differ between the events internally. The
> > API right now is very similar to libinput's events so integrating it into a
> > compositor should be trivial.
> > 
> > b) is somewhat handwavy if an application runs outside a sandbox - any
> > information will be unreliable. Flatpak gives you an app-id though and
> > with that we can (eventually) do things like storing the allow/deny
> > decisions of the user in the portal implementation.
> > 
> > c) allows you to e.g. suspend the client when convenient or just ignore
> > certain sequences altogether. The two made-up examples are: suspend EI
> > during a password prompt, or allow EI from the software yubikey *only*
> > during a password prompt.
> 
> We don't want any application be able to inject input events. How should
> a program such as synergy authenticate itself? or is it completely up to
> the compositor to decide what the authentication process looks like?

The currently available method for application authenticaion is using
portals from an application sandbox. The portal will know from what
application a request to open a channel comes from without having to
trust the application to tell the truth, and provide user facing ways
for potentially limiting access. In other words, it'd be blocked before
ever reaching the display server would so be needed. What this proposal
aims is to create is (among other things) a portal (i.e. an API on
org.freedesktop.portal.*) that does this.

Other ways would be to make it slightly harder for applications to
get access, e.g. only provide a socket name to certain ones, but that'd
rely on trusting applications not to try bad things, and may have other
limitations.


Jonas