On Wed, 1 Nov 2017 13:44:50 -0500 Matt Hoosier <matt.hoos...@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
pgpKzUie8okbF.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel