Enabling Android-style per application user ids

Thu Nov 2 15:07:28 UTC 2017

On Thu, Nov 2, 2017 at 3:36 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

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

Agreed. The server side here is not the problem. The existing systemd
integration already makes it very simple to provide as many different
listening-socket locations as needed.

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

Exactly.

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

This would definitely work, so I don't object if this is the preference of
other reviewers. I would prefer (for the reasons coming below) the
/run/wayland/$WAYLAND_DISPLAY suggestion though.

One note about this: this would contain a subtle change in behavior to
existing users of $WAYLAND_DISPLAY. If somebody sets
WAYLAND_DISPLAY="/wayland-0" currently, this works okay. The concatenation
logic in wl_display_connect() results in a string
"/run/user/<uid>//wayland-0", which is valid despite the duplicate '/'. If
$WAYLAND_DISPLAY is now examined for absolute-pathiness, the logic would
probably see "/wayland-0" as an absolute path reference, and the connection
attempt would fail.

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

Right. I think this doesn't scale well to descendants of the
explicitly-arranged clients either.

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

This would be my preference. The fewer tweaks to environment variables are
required, the better in my opinion.

>
>
> Thanks,
> pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171102/e687a709/attachment.html>