[RFC] Interface for injection of input events
Christopher James Halse Rogers
christopher.halse.rogers at canonical.com
Tue Mar 28 21:44:49 UTC 2017
On Tue, 28 Mar 2017 at 22:31 Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Tue, 28 Mar 2017 16:20:28 +0900
> Carsten Haitzler (The Rasterman) <raster at rasterman.com> wrote:
> > On Wed, 22 Mar 2017 13:59:43 +0200 Pekka Paalanen <ppaalanen at gmail.com>
> > > > == Authentication/Identification ==
> > > > The goal is to filter clients based on some white/blacklist, so that
> > > > xdotool can access this interface but others cannot.
> > >
> > > Hi,
> > >
> > > if one allows a generic tool that essentially exposes everything at
> > > will, there isn't much point in authenticating that program, because
> > > any other program can simply call it.
> > This is where right now I might lean to some environment variable with a
> > cookie/key the compositor provides *and that may change from session to
> > or on demand).
> > So compositor might putenv() then fork() + exec() something like a
> > app.. and then this terminal app and anything run from it inherits this
> > var... and thus now has the secret key to provide...
> > This also allows the compositor to run any such process that passes the
> > key/cookie along to other processes/tools it determines are safe. It
> > require the compositor have a "safe user initiated or approved" way to
> run such
> > things.
> that doesn't sound too bad. Initially the cookie could be passed in the
> env, until something better comes around. Also the restrictions and
> privileges carried with a cookie could vary based on how it was
> generated, e.g. cookies created for a container could be invalid for
> clients outside that specific container. Or require matching to SElinux
> or SMACK or whatever attributes. Or none of these at first. Completely
> up to the compositor.
> So now we need a spec for the cookie. An opaque binary blob with
> variable size, limited by some maximum size? 1 kB max?
> (To ensure e.g. Wayland can relay the maximum sized cookie in one
> This could be the generic starting point for all privileged interfaces,
> Wayland and others. How the client will get the cookie in the first
> place is left undefined. The cookie should probably be optional too, in
> case another scheme already grants the privileges.
> Giulio, how about incorporating such a cookie scheme in your
> restricted_registry design?
> one, is that useful? Do we have to spec the env variable?
FWIW, an HMAC cookie is how we handle various privileged actions in Mir
(raise window, drag & drop [because most of D&D is handled
out-of-compositor]), so this would be easy to integrate for us.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel