New paths for Wayland sockets (Re: Enabling Android-style per application user ids)

[Ucan, Emre (ADITG/ESB)]

Hi,

I am for supporting absolute paths with WAYLAND_DISPLAY. Because this approach is more flexible than other proposal.

Best regards

Emre Ucan
Engineering Software Base (ADITG/ESB)

Tel. +49 5121 49 6937

> -----Original Message-----
> From: wayland-devel [mailto:wayland-devel-
> bounces at lists.freedesktop.org] On Behalf Of Pekka Paalanen
> Sent: Freitag, 3. November 2017 08:34
> To: Matt Hoosier; wayland mailing list
> Cc: Davide Bettio; Martin Flöser; Jonas Ådahl; raster at rasterman.com
> Subject: New paths for Wayland sockets (Re: Enabling Android-style per
> application user ids)
> 
> On Thu, 2 Nov 2017 10:07:28 -0500
> Matt Hoosier <matt.hoosier at gmail.com> wrote:
> 
> > 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:
> > >
> 
> > > >
> > > > 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}.
> 
> Hi,
> 
> I rewrote the subject with the hope to raise more interest, being more
> specific to the proposals.
> 
> > > 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.
> 
> While this is true, I don't think it is a blocker unless we find out
> about tools or compositors doing so.
> 
> 
> > >
> > > 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.
> 
> Right, so there is interest to both ideas, and I don't see them as
> mutually exclusive. I believe one can also write a good justification
> for each, so now I'd be looking for reasons why either might be
> unwanted and acks for each, so that we get enough buy-in to "bless" the
> behavioural change in libwayland-client.
> 
> People, give your acks/nacks for the two ideas, please:
> 
> - modify WAYLAND_DISPLAY to support absolute paths which overrides
>   any search paths
> 
> - when the current socket search fails, add one more place to look
>   in: /run/wayland/$WAYLAND_DISPLAY with the default "wayland-0" if
>   WAYLAND_DISPLAY is not set.
> 
> 
> The last proposed patch for absolute paths is probably
> https://lists.freedesktop.org/archives/wayland-devel/2015-
> August/023838.html
> which looks like it got ignored mostly because of a damaged submission
> and mixed-up (nowadays probably unwanted) server-side changes. The
> patch also lacks the rationale and justification in the commit message.
> This is FYI for anyone wanting to carry on that work.
> 
> 
> Thanks,
> pq