[RFC] Interface for injection of input events

[Pekka Paalanen]

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?


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/20170328/25c5ddef/attachment.sig>