2013/12/17 Bill Spitzak <[email protected]>: > On 12/17/2013 02:38 AM, Giulio Camuffo wrote: > >> You can't talk to another client directly, you must always pass >> through the server (unless you use dbus or some other ipc, of course). >> And you don't need to give the trusted client a key, you just need to >> tell the server some client is trusted, using the same mechanism >> weston uses internally to launch trusted clients. That's what the >> links I posted are doing. > > > I think I see. So a trusted client can exec another client and make it > trusted as well. > > Is there any way for the first client to restrict how "trusted" the second > client is? What I imagine is a first client that has access to every wayland > api. It would like to run the screen saver and only give it screen-saver > access. >
Yes. In my implementation i pass an interface name together with the fd, and the client is trusted only for that. > Also is this api available for untrusted clients? Can a parent client create > a surface, then using this api exec another client, and that child client is > able to attach buffers to that surface? Those are two different questions. The api is only available to the shell client (so a trusted client) in my implementation, though that's not required technically. You can't attach a buffer to another's client surface because there is no way for the client to refer to that surface, and this api doesn't change that. For that a new protocol extension would be needed. > > What I was trying to propose is a way for one client to choose exactly what > objects another client can use. It would give that other client a "key" > (using dbus or argv or other ipc, not using wayland). That other client then > sends a message to the wayland server with the "key" and receives the actual > object. > _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
