Enabling Android-style per application user ids

[Pekka Paalanen]

On Wed, 1 Nov 2017 13:44:50 -0500
Matt Hoosier <matt.hoosier at gmail.com> wrote:

> 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.

Hi Matt,

this is all true. There have been suggestions before about adding
various forms of environment variables to libwayland-client and
libwayland-server to divert the socket creation and finding, but they
died in either lack of review, interest, or having a hacky feel to
them.

Personally I recall being not fond of the server side environment
variables at least, because libwayland-server has API for creating
sockets in arbitrary places already, you just need to write your
compositor to use it.

The API in question is the wl_display_add_socket*() set of functions.
It is even possible to configure the sockets in a systemd unit file and
have Weston use those automatically via the systemd-notify.so plugin.
At least I see the code in there.

But that was about the server side, while the real problem is in the
client side, as you say.

There is one more possibility in addition to having a single socket
somewhere findable and usable for all: creating application-user
specific sockets from the compositor or from systemd before launching
the compositor.

If you created application-user specific sockets and your
application-users are properly isolated, you could identify the
connecting application(-user) by the socket it is coming in through.
That way the server could authenticate different client groups. The
catch is that I don't think libwayland-server has the API to query how
a wl_client got connected, so that's something we would need to work on
if it seems useful.

I can also imagine that it may not be feasible to create
application-user specific sockets for everything, so there could be a
need for a common socket file somewhere that is not tied to
XDG_RUNTIME_DIR. With a good justification written down, I suspect that
would be fine. We just need to figure out the details on how to do that
exactly.

Modifying the meaning of WAYLAND_DISPLAY environment variable to
support also absolute paths has been proposed before IIRC. Maybe
resurrecting that work could be a way forward? Can anyone see a problem
with that?

Right now, I would think that extending WAYLAND_DISPLAY might be better
than introducing new environment variables to further modify the
automatic socket finding in libwayland-client.

wl_display_connect_to_fd() would allow clients to connect to arbitrary
sockets, but I understand that to be an unattractive solution in
general, because it would need modifying client toolkits to use it.
There is also WAYLAND_SOCKET, but it is probably not often possible to
arrange an already open connection in a general case.

The suggestion to automatically look for a fallback socket
at /run/wayland/$WAYLAND_DISPLAY with WAYLAND_DISPLAY defaulting to
"wayland-0" sounds reasonable to me, but I wouldn't feel comfortable
making that review decision alone. I do know some people are eager to
avoid mandatory environment variables if something can be found by
convention.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171102/52aef7cb/attachment.sig>