[RFC] Interface for injection of input events
ppaalanen at gmail.com
Wed Mar 29 11:03:58 UTC 2017
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)
Simon (CC'd) wanted to provide us with some insight, so I'm relaying
- 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
- end quote -
The blog post he refers to is:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel