<div dir="ltr"> <div class="gmail_quote"><div dir="ltr">On Tue, 28 Mar 2017 at 22:31 Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 28 Mar 2017 16:20:28 +0900 Carsten Haitzler (The Rasterman) <<a href="mailto:raster@rasterman.com" class="gmail_msg" target="_blank">raster@rasterman.com</a>> wrote: > On Wed, 22 Mar 2017 13:59:43 +0200 Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" class="gmail_msg" target="_blank">ppaalanen@gmail.com</a>> 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? </blockquote><div> </div><div>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. </div></div></div>