Skip to content
Snippets Groups Projects
  • Simon McVittie's avatar
    a2734181
    run: Preserve X11 display number instead of redirecting it to :99 · a2734181
    Simon McVittie authored
    Suppose the user's "real" X11 display on the host is Xorg or Xwayland
    listening on :42, but they also have an Xvfb server listening on :99.
    
    If we change the X11 display number to the arbitrary value :99, and
    the Flatpak sandbox shares its network namespace with the host, then
    clients inside the Flatpak sandbox will prefer to connect to the
    abstract socket @/tmp/.X11-unix/X99 (which is Xvfb), rather than the
    filesystem-backed socket /tmp/.X11-unix/X99 in the sandbox (which is
    really /tmp/.X11-unix/X42 on the host, i.e. Xorg or Xwayland).
    
    If they're relying on Xauthority (MIT-MAGIC-COOKIE-1) for access
    control (as many display managers do), then this will fail, because
    we gave the sandboxed app access to the cookies for Xorg/Xwayland
    (rewriting their display number from 42 to 99 as we did so), but
    Xvfb does not accept those cookies.
    
    If we're relying on `xhost +"si:localuser:$(id -nu)"` for access control
    (as gdm does), then the Flatpak app will successfully (!) connect to
    whatever is on :99, for example Xvfb or Xephyr, which is rarely what
    anyone wants either.
    
    Resolves: https://github.com/flatpak/flatpak/issues/3357
    Forwarded: https://github.com/flatpak/flatpak/pull/5034
    Resolves: https://github.com/ValveSoftware/steam-runtime/issues/524
    
    
    Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
    a2734181
    History
    run: Preserve X11 display number instead of redirecting it to :99
    Simon McVittie authored
    Suppose the user's "real" X11 display on the host is Xorg or Xwayland
    listening on :42, but they also have an Xvfb server listening on :99.
    
    If we change the X11 display number to the arbitrary value :99, and
    the Flatpak sandbox shares its network namespace with the host, then
    clients inside the Flatpak sandbox will prefer to connect to the
    abstract socket @/tmp/.X11-unix/X99 (which is Xvfb), rather than the
    filesystem-backed socket /tmp/.X11-unix/X99 in the sandbox (which is
    really /tmp/.X11-unix/X42 on the host, i.e. Xorg or Xwayland).
    
    If they're relying on Xauthority (MIT-MAGIC-COOKIE-1) for access
    control (as many display managers do), then this will fail, because
    we gave the sandboxed app access to the cookies for Xorg/Xwayland
    (rewriting their display number from 42 to 99 as we did so), but
    Xvfb does not accept those cookies.
    
    If we're relying on `xhost +"si:localuser:$(id -nu)"` for access control
    (as gdm does), then the Flatpak app will successfully (!) connect to
    whatever is on :99, for example Xvfb or Xephyr, which is rarely what
    anyone wants either.
    
    Resolves: https://github.com/flatpak/flatpak/issues/3357
    Forwarded: https://github.com/flatpak/flatpak/pull/5034
    Resolves: https://github.com/ValveSoftware/steam-runtime/issues/524
    
    
    Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>