On Tue, 28 Mar 2017 at 22:31 Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Tue, 28 Mar 2017 16:20:28 +0900 > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > On Wed, 22 Mar 2017 13:59:43 +0200 Pekka Paalanen <ppaala...@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.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel