Enabling Android-style per application user ids

Matt Hoosier matt.hoosier at gmail.com
Wed Nov 1 18:44:50 UTC 2017


There has been a surge of recent interest in the details of using Wayland
on nontraditional systems that don't have the normal notion of human-user
login sessions. Discussions are ongoing about the details of how to manage
the allocation of TTYs and Weston's vision of the best practices for
assigning Unix ownership modes to the hardware devices. Set those aside for
the moment though.

I'd like to call attention to another difficult point in using Wayland for
a device that acts more like a smartphone than a desktop: the main logic in
wl_display_connect() always attempts to contact a server socket living at
${XDG_RUNTIME_DIR}/${WAYLAND_DISPLAY}.

This creates a problem for a device that isolates each application in a
different user ID. XDG_RUNTIME_DIR is expressly defined as a directory
which is private to its user. The system must either abusively point
numerous users' XDG_RUNTIME_DIR's all at the same path, or use an
out-of-band hack such as hardlinking each application uid's
/run/user/<application uid>/wayland-0 path to the true server socket
/run/user/<weston uid>/wayland-0.

As a consequence, it is difficult to implement a security model similar to
Android's, on a device that's adopted Wayland.

I can imagine several schemes for allowing a generic Wayland client program
to transparently find some systemwide compositor instance. The client could
automatically attempt to open /var/run/${WAYLAND_DISPLAY} if
${XDG_RUNTIME_DIR}/${WAYLAND_DISPLAY} doesn't exist. That approach could
also be modified to require the client to explicitly opt-in by setting some
environment variable such as WAYLAND_RUNTIME_DIR that is treated as a
fallback if XDG_RUNTIME_DIR contains no server socket.

Thoughts? It's very encouraging to see all the technical capabilities that
allow Wayland/Weston to be a credible option for making embedded devices
with great graphics support, but there are a few rough edges such as these
that make deployment a challenge.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171101/d42bf861/attachment.html>


More information about the wayland-devel mailing list