[RFC] Interface for injection of input events

[Christopher James Halse Rogers]

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>
> said:
> >
> > > > == 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.
> > >
> > > 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
> session
> > or on demand).
> >
> > So compositor might putenv() then fork() + exec() something like a
> terminal
> > app.. and then this terminal app and anything run from it inherits this
> env
> > 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
> would
> > require the compositor have a "safe user initiated or approved" way to
> run such
> > things.
>
> Hi,
>
> 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
> message.)
>
> 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?
>
> OTOH, a spec that uses cookies but does not tell where you might get
> 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...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170328/d501a07d/attachment.html>