[RFC] Interface for injection of input events

[Pekka Paalanen]

On Wed, 22 Mar 2017 12:23:46 +1000
Peter Hutterer <peter.hutterer at who-t.net> wrote:

> Hi all,
> 
> This is an RFC for a new interface to generate input events from arbitrary
> clients. Note that this is only a few days old, so **do not** assume this is
> anything more a thought experiment right now. This email is supposed to start a
> discussion and collection of the various points that need to be addressed.
> 
> First: why? There are some commandline tools like xdotool that allow for some
> scripting of desktop interactions. xdotool supports two categories: input
> device emulation and window management.
> 
> This RFC primarily addresses the input device emulation bits but there is
> room for adding window management capabilities. I have a basic repo here:
> http://github.com/whot/woodotool but it doesn't contain much beyond what's
> in this email.
> 
> This will be a discussion of the interface only because the implementations
> are so specific that there is no real code-sharing beyond the interface
> itself. I've talked privately to some of you already, the general mood is
> somewhere around reluctant acceptance.
> 
> So here's a list of talking points:
> 
> == DBus ==
> What we need is basic IPC and not directly Wayland related, DBus provides a
> bunch of extras over the wayland protocol: introspection, ease of
> extensibility, bindings, etc. Also, Mir.
> 

> == Authentication/Identification ==
> The goal is to filter clients based on some white/blacklist, so that e.g.
> xdotool can access this interface but others cannot.
> 
> This is a big ¯\_(ツ)_/¯ for now, I don't now how to do this reliably.
> It's trivial to do per user, but per-process is difficult. DBus filters
> are largely limited to per-users. It's possible to get the process ID of a
> sender but going beyond that is unreliable (kernel doesn't guarantee comm
> being accurate).
> 
> Requiring applications to bind to a bus name merely restricts them to being
> a singleton, there is no guarantee the application that binds
> org.freedesktop.org.WoodoTool.auth.xdotool is actually xdotool.
> 
> The option that comes closest so far is some pre-shared key between
> compositor and application. That would need to be worked into the API, but
> it also relies on all participants to keep the key encrypted in memory and
> the various configuration files.
> 
> So it's not clear whether we can do anything beyond a basic on/off toggle on
> whether to allow events from fake input devices. Debatable if such a crude
> mechanism is useful.
> 
> 
> Either way, this is a problem that *must* be solved but not necessarily one
> that affects the API itself (beyond what is required to make it
> technically feasable, e.g. passing cookies around)

Hi all,

Simon (CC'd) wanted to provide us with some insight, so I'm relaying
his message:

- quote -

The first thing to say about app identity is that anything backed by
AF_UNIX, like D-Bus and (AIUI) Wayland, is very limited in the
statements it can make about a peer's identity without race conditions.
It can get the uid that opened the socket, the LSM (AppArmor, SELinux,
Smack) label, and the pid, and that's about it. Anything involving
reading from /proc/$pid has a race condition against pid reuse, and
some things are also vulnerable to a worse race condition involving
exec()ing a setuid/etc. binary. So the only way you can possibly do
identity reliably is to do some sandboxing, and have there be
something, like a secret or an AF_UNIX socket, that only trusted
processes can get to.

https://bugs.freedesktop.org/show_bug.cgi?id=100344 (which I blogged
about recently) is how I'm hoping to resolve that for D-Bus, time
permitting.

- end quote -

The blog post he refers to is:
http://smcv.pseudorandom.co.uk/2017/dbus_and_containers/


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/20170329/37097c55/attachment-0001.sig>