New paths for Wayland sockets (Re: Enabling Android-style per application user ids)
jadahl at gmail.com
Wed Nov 8 08:29:03 UTC 2017
I'd just like to point out that changing WAYLAND_DISPLAY to be able to
point to a socket using an absolute path is not completely backward
compatible. In the wl_display_connect() documentation it says that
"The server socket must be placed in <envar>XDG_RUNTIME_DIR</envar> for
this function to find it."
Some clients may have used this knowledge for processing before handing
anything over to libwayland-client.
One example of something that will break without further adaptations is
(although not a client) flatpak, which currently expose the socket
inside the sandbox by manually binding it.
So, in other words, if this feature is to be added, it must be made
clear what the guarantees regarding backward compatibility may be.
On Tue, Nov 07, 2017 at 10:51:42AM -0600, Matt Hoosier wrote:
> Hi Pekka,
> What do you think is a good amount of time to allow for people to
> respond to your call for acks/nacks?
> On Fri, Nov 3, 2017 at 8:33 AM, Carsten Haitzler <raster at rasterman.com> wrote:
> > On Fri, 3 Nov 2017 12:47:39 +0200 Pekka Paalanen <ppaalanen at gmail.com> said:
> >> On Fri, 3 Nov 2017 11:04:27 +0100 (CET)
> >> Jan Engelhardt <jengelh at inai.de> wrote:
> >> > On Friday 2017-11-03 10:37, Pekka Paalanen wrote:
> >> > >
> >> > >> Summary of (individual) proposals follows.
> >> > >>
> >> > >> >- modify WAYLAND_DISPLAY to support absolute paths which overrides
> >> > >> > any search paths
> >> > >>
> >> > >> - introduce new WAYLAND_SOCKET
> >> > >> - modify WAYLAND_DISPLAY to reject '/'
> >> > >
> >> > >What would be the functional difference to WAYLAND_DISPLAY accepting
> >> > >absolute paths? Why would a different environment variable make a
> >> > >difference?
> >> >
> >> > Well because you cannot establish for certain that people have or have not
> >> > already used WAYLAND_DISPLAY=/newsock in the concatenation sense.
> >> >
> >> > (Depending on who you ask and how much weight they give to it,
> >> > breaking application interfaces is out of the question. That's all.)
> >> Ah, that, ok. I thought this was about the security stuff you referred
> >> to. But given the same rationale, we cannot forbid / in WAYLAND_DISPLAY
> >> either.
> > security here i think is a red herring. i can effectively trick
> > libwayland-client to connect to an abs path by setting XDG_RUNTIME_DIR AND
> > WAYLAND_DISPLAY. so ... effectively same thing. it will force all xdg runtime
> > stuff to be in that same dir... but i think abs path for wl display
> > specifically being a security issue is a red herring, unless there is something
> > none of us can think of. then we have the problem already with runtime dir env
> > var and wl display too like above.
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > Carsten Haitzler - raster at rasterman.com
More information about the wayland-devel