On Mon, 16 Dec 2013 01:51:20 +0100
Sebastian Wick <sebast...@sebastianwick.net> wrote:
> Am 2013-12-16 00:52, schrieb Timothée Ravier:
> > polkit could also be used for the whole process of deciding whether
> > a screenshot action is allowed or not:
> >
> > * The compositor would first request authorization for the
> > screenshot action to polkit;
> > * polkit would check if the action is legitimate using the
> > authorization
> > rules defined on the system;
> > * If no rules matches, a dialog requesting confirmation by the user
> > is displayed;
> > * If the polkit answer is positive, the compositor would launch the
> > screenshot application.
> >
> > Adding rules is a little bit more difficult in this case, but this
> > has the advantage of reusing an already developed architecture.
> >
> > Cheers
>
> Sounds like a good plan but I still don't understand why the
> application must be started by the compositor. What exactly is the
> benefit?
I'm not sure Timothée actually implied that in the above, but here is
the explanation anyway.
When the compositor is about to launch an app, it can create the
communication socket pair in advance, which means that the app is
already a connected client when it starts. The app will not be opening
a socket file to create a new connection to the compositor. That
guarantees, that the already open connection fd the compositor has is
tied to the exact process (or grandchild etc) the compositor forked.
You do not have to try to authenticate a new connection coming in via
the usual socket file opening. You only need to make sure the binary the
compositor is exec'ing is trusted.
See weston_client_launch() for an example of how this is done:
1. socketpair() returns two open fds that are connected to each other
2. a child process is forked, and it inherits both fds
3. the parent process closes one end of the socket pair
4. the child process closes the other end of the socket pair
5. the parent process creates a client connection straight from the
remaining open fd
6. the child process dup's its remaining open fd so it won't get closed
on exec()
7. the child process sets the environment variable WAYLAND_SOCKET to
the fd number from dup()
8. the child process exec()'s the application
9. libwayland-client in the application reads WAYLAND_SOCKET, and uses
that already open fd as the connection to the compositor
This avoids authenticating an initially untrusted connection by having
the connection trusted from the start.
Thanks,
pq
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
