On Thu, 2 Nov 2017 10:36:31 +0200 Pekka Paalanen <[email protected]> said:
> On Wed, 1 Nov 2017 13:44:50 -0500 > Matt Hoosier <[email protected]> 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 - [email protected] _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
