On Wed, 22 Mar 2017 12:23:46 +1000 Peter Hutterer <peter.hutte...@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
pgpQ3kxwW6ygj.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel