Summary of the security discussions around Wayland and privileged clients
jason at jlekstrand.net
Thu Feb 20 14:07:22 PST 2014
On Thu, Feb 20, 2014 at 2:41 PM, Thiago Macieira <thiago at kde.org> wrote:
> Em qui 20 fev 2014, às 21:31:59, Martin Peres escreveu:
> > > Now, the privileged process wants to launch a sub-process. How will the
> > > sub- process connect to the compositor? Remember: WAYLAND_SOCKET
> > > a file descriptor number that isn't available to the child process.
> > Ah, I see. You are suggesting un-setting WAYLAND_SOCKET and using
> fcntl() to
> > set the socket's fd to CLOEXEC?
> Setting the socket to O_CLOEXEC is mandatory after you start using it. Two
> processes cannot write to the same streaming socket file descriptor at the
> time. You might be able to do this with a datagram socket, but that's not
> case here.
> > It is true that multiple process could end up with the same connection
> > I didn't think about that. The problem is the same if an application
> > connects
> > to the compositor by itself and then forks. Not sure how the compositor
> > could detect that :s
> It can't. It will get very confused because two applications with
> states will start stepping on each other's toes. The best outcome of this
> would be if the compositor detected a problem early on and cut the
> to both.
> The way I see it, wl_display_connect() must unset the WAYLAND_SOCKET
> environment variable after getting the file descriptor number and it must
> O_CLOEXEC. The socket is not available to child processes.
It already does both of these:
> But then the question returns: how do child processes connect to the
> compositor, if the environment variable was cleared? How do they find the
> 1) the compositor MUST have a well-known socket name
> => not an option, since we want to have multiple concurrent compositors
> 2) wl_display_connect() doesn't clear the environment, but resets it to the
> actual socket name. It needs to get the socket name from somewhere.
> => problem: if it's getting the name from the compositor, this may take a
> few roundtrips and the process may have decided to start the child
> 3) use a different environment variable. One variable contains the
> socket path and the other contains the file descriptor. The latter
> the former.
This is what we are doing right now. The WAYLAND_DISPLAY environment
variable contains the name of a socket that can be found in
XDG_RUNTIME_DIR. The WAYLAND_SOCKET environment variable (if it exists)
contains a file descriptor that a single client can use to connect to the
compositor. Inside wl_display_connect, we clear WAYLAND_SOCKET but not
WAYLAND_DISPLAY. If both are present, the client connects directly and is
then free to spawn other clients which will connect via WAYLAND_DISPLAY.
However, those other clients will not have the same priviledged status
because they didn't use the direct connection. This is the way Weston's
desktop-shell panel spawns things right now.
> 4) store both settings in WAYLAND_SOCKET. D-Bus does that:
> DBUS_SESSION_BUS_ADDRESS can contain multiple addresses, to be attempted in
That's an interesting idea. Not sure what benefit it would have for
Wayland right now though.
Hope that helps,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel