Enabling Android-style per application user ids

[Carsten Haitzler]

On Thu, 2 Nov 2017 10:36:31 +0200 Pekka Paalanen <ppaalanen at gmail.com> said:

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

I'd vote for this above because of simplicity and obviousness.

> 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


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com