[RFC] Interface for injection of input events

Carsten Haitzler (The Rasterman) raster at rasterman.com
Tue Mar 28 07:20:28 UTC 2017


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.

Unless there is some other mechanism that could work like this.

> > 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)
> 
> It's essentially the same problem we have with all the privileged
> Wayland interfaces, too.
> 
> Containers or sandboxing have been mentioned as a possible way to let
> the OS reliably identify the running program.

At least as a way to avoid them leaking keys like above example... then a
sandboxed system can ensure sandboxed processes don't have access to such
cookies/keys but otherwise compositors themselves do not have to support a
SPECIFIC sandboxing mechanism... :) they simply auth/compare the cookie/key.
the compositor could also have several cookies/keys and revoke any it chooses
to at any time and different clients are provided different keys.

Either way, security has been an elephant in the room for a while and we don't
really have a consensus on how to support extra privileges other than to say
"don't do it at all" or "not a wayland problem". :(

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com



More information about the wayland-devel mailing list