<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 2, 2017 at 3:36 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On Wed, 1 Nov 2017 13:44:50 -0500<br>
Matt Hoosier <<a href="mailto:matt.hoosier@gmail.com">matt.hoosier@gmail.com</a>> wrote:<br>
<br>
> There has been a surge of recent interest in the details of using Wayland<br>
> on nontraditional systems that don't have the normal notion of human-user<br>
> login sessions. Discussions are ongoing about the details of how to manage<br>
> the allocation of TTYs and Weston's vision of the best practices for<br>
> assigning Unix ownership modes to the hardware devices. Set those aside for<br>
> the moment though.<br>
><br>
> I'd like to call attention to another difficult point in using Wayland for<br>
> a device that acts more like a smartphone than a desktop: the main logic in<br>
> wl_display_connect() always attempts to contact a server socket living at<br>
> ${XDG_RUNTIME_DIR}/${WAYLAND_<wbr>DISPLAY}.<br>
><br>
> This creates a problem for a device that isolates each application in a<br>
> different user ID. XDG_RUNTIME_DIR is expressly defined as a directory<br>
> which is private to its user. The system must either abusively point<br>
> numerous users' XDG_RUNTIME_DIR's all at the same path, or use an<br>
> out-of-band hack such as hardlinking each application uid's<br>
> /run/user/<application uid>/wayland-0 path to the true server socket<br>
> /run/user/<weston uid>/wayland-0.<br>
><br>
> As a consequence, it is difficult to implement a security model similar to<br>
> Android's, on a device that's adopted Wayland.<br>
><br>
> I can imagine several schemes for allowing a generic Wayland client program<br>
> to transparently find some systemwide compositor instance. The client could<br>
> automatically attempt to open /var/run/${WAYLAND_DISPLAY} if<br>
> ${XDG_RUNTIME_DIR}/${WAYLAND_<wbr>DISPLAY} doesn't exist. That approach could<br>
> also be modified to require the client to explicitly opt-in by setting some<br>
> environment variable such as WAYLAND_RUNTIME_DIR that is treated as a<br>
> fallback if XDG_RUNTIME_DIR contains no server socket.<br>
><br>
> Thoughts? It's very encouraging to see all the technical capabilities that<br>
> allow Wayland/Weston to be a credible option for making embedded devices<br>
> with great graphics support, but there are a few rough edges such as these<br>
> that make deployment a challenge.<br>
<br>
</div></div>Hi Matt,<br>
<br>
this is all true. There have been suggestions before about adding<br>
various forms of environment variables to libwayland-client and<br>
libwayland-server to divert the socket creation and finding, but they<br>
died in either lack of review, interest, or having a hacky feel to<br>
them.<br>
<br>
Personally I recall being not fond of the server side environment<br>
variables at least, because libwayland-server has API for creating<br>
sockets in arbitrary places already, you just need to write your<br>
compositor to use it.<br>
<br>
The API in question is the wl_display_add_socket*() set of functions.<br>
It is even possible to configure the sockets in a systemd unit file and<br>
have Weston use those automatically via the systemd-notify.so plugin.<br>
At least I see the code in there.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
But that was about the server side, while the real problem is in the<br>
client side, as you say.<br></blockquote><div><br></div><div>Exactly.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
There is one more possibility in addition to having a single socket<br>
somewhere findable and usable for all: creating application-user<br>
specific sockets from the compositor or from systemd before launching<br>
the compositor.<br>
<br>
If you created application-user specific sockets and your<br>
application-users are properly isolated, you could identify the<br>
connecting application(-user) by the socket it is coming in through.<br>
That way the server could authenticate different client groups. The<br>
catch is that I don't think libwayland-server has the API to query how<br>
a wl_client got connected, so that's something we would need to work on<br>
if it seems useful.<br>
<br>
I can also imagine that it may not be feasible to create<br>
application-user specific sockets for everything, so there could be a<br>
need for a common socket file somewhere that is not tied to<br>
XDG_RUNTIME_DIR. With a good justification written down, I suspect that<br>
would be fine. We just need to figure out the details on how to do that<br>
exactly.<br>
<br>
Modifying the meaning of WAYLAND_DISPLAY environment variable to<br>
support also absolute paths has been proposed before IIRC. Maybe<br>
resurrecting that work could be a way forward? Can anyone see a problem<br>
with that?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Right now, I would think that extending WAYLAND_DISPLAY might be better<br>
than introducing new environment variables to further modify the<br>
automatic socket finding in libwayland-client.<br>
<br>
wl_display_connect_to_fd() would allow clients to connect to arbitrary<br>
sockets, but I understand that to be an unattractive solution in<br>
general, because it would need modifying client toolkits to use it.<br>
There is also WAYLAND_SOCKET, but it is probably not often possible to<br>
arrange an already open connection in a general case.<br></blockquote><div><br></div><div>Right. I think this doesn't scale well to descendants of the explicitly-arranged clients either.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The suggestion to automatically look for a fallback socket<br>
at /run/wayland/$WAYLAND_DISPLAY with WAYLAND_DISPLAY defaulting to<br>
"wayland-0" sounds reasonable to me, but I wouldn't feel comfortable<br>
making that review decision alone. I do know some people are eager to<br>
avoid mandatory environment variables if something can be found by<br>
convention.<br></blockquote><div><br></div><div>This would be my preference. The fewer tweaks to environment variables are required, the better in my opinion.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div></div>