On 16/12/2013 22:32, Bill Spitzak wrote: > Could an api be added so that one client can "give" access to an object > to another client? This would allow a single secure client to implement > all the rules for what is allowed to be a screen saver, rather than > having the rules be in the compositor. > > What I thought was something like this: > > - "secure" client gets the object id for the screen shooter api > > - It can ask the compositor for a "key" to this id. This is a big > random-looking number
Being a big random does not really make it "secure", as this can still be guessed theoretically. Passing a socket fd to a child process leaves no room for security approximation. Do you see any downsides to the compositor launching the screenshot application? > Speaking from a user pov: > > If the user wants to run a screen saver app they downloaded, then when > they run it the first time it should pop up a dialog saying "this app > wants to be able to take images of the screen" and if the user hits ok > it runs. That's what I suggested, with a user's password prompt maybe, to make sure the dialog is not just clicked through. > Anything more complicated than that, including anything > requiring the screen shooter to be "installed" or giving it setuid, is > unacceptable. The install part is just a way to avoid prompting the user for "official" packaged screenshot applications. No setuid application is involved here. However, I can't think of a way to make the "remember this application and don't ask me latter" feature work and be secure without a privilege elevation to store this setting. -- Timothée Ravier _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel