Moving the X11 socket to XDG_RUNTIME_DIR

[Carsten Haitzler]

On Fri, 04 Jul 2025 01:07:23 +0100 "Artur Manuel" <amad at atl.tools> said:

> On Thu Jul 3, 2025 at 7:44 AM BST, Carsten Haitzler wrote:
> > so do you propose the xserver sets up these symlinks? if x is running as
> > $USER then putting it in the xdg runtime dir makes sense. but then... you
> > have issues with multiple users fighting over /tmp/.X11-unix for the compat
> > symlinks (in the in the case of 2 x sessions running as 2 users on
> > different vt's etc.).
> It wouldn't really be a fight, since you would assign a new $DISPLAY
> value anyway (:1 rather than :0) and that would be reflected in the
> socket directory. I'm pretty sure it would be bad if your user is trying
> to fight for the same DISPLAY.

well.. to the effect that /tmp/.X11-unix may not be owned by the same user as
the socket file and will need global write ability to that dir so anyone can
create files there...

> > i agree in principle a xorg running as $USER (not root) would be a
> > cleaner/better solution with the socket where you propose... but changing
> > this has implications for compatibility.
> Indeed it could break compatibility but I believe you can handle this in
> such a way where this isn't a problem. The root user can also have an
> XDG_RUNTIME_DIR directory anyway (and it would be even more secure in
> that case since you can now no longer hijack the root's X11 socket and
> have an albeit tedious way of accessing root without needing the
> password.) To make it brief: compatibility should not be the main
> concern, security should be.

if compatibility was not a concern of x - we should have broken various bits of
protocol long ago instead of just adding on. :) i'm pointing out that you are
proposing a break (without symlinks) and that needs to be walked into with eyes
wide open as to the implications. that's my point. not just static binaries by
any kind of chroots where you bind mount /tmp/.X11-unix and other sandboxes too
fall under this banner. it might be much more widely spread now that i think
about it.

> > this is a choice of "keep compat" or "improve things and maybe break a few
> > things on the way".
> >
> > i PERSONALLY would vote for small breaks like this as being acceptable for
> > their improvements, as i would also vote in general for improvements to xorg
> > and protocols if they broke things in clever and well through out ways to
> > make it a better place. i'm just pointing out that there is an issue that
> > comes along with this.
> I agree. I would rather not have security implications because some
> noteworthy app hardcoded the position of the X11 socket and it would
> break if said path were to change. This is mostly a non-issue anyway as
> there doesn't seem to be, in my perspective, a way this would break
> compatibility. I would agree that it may cause issues though.

see above. sandbox env's are an issue - they may have an "old xlib" that
doesn't know where to now look for the socket and well.. they now fall over.
the sandbox could have adapted to the current setup and ensured sockets are
there and shared for X11 but now may not ... and symlinks would not work here
as he paths may be different and users different etc.

point of discussion being -> let's sort out how much this breaks and see if we
can maybe come up with solutions before breaking anything - if we're down
to the utterly obscure "there are 3 of these in existence with 2 users
left" or something... then maybe we can discount them. :)

> I hope I wasn't too annoying in my points. Once again, cheers,
> -- 
> Artur Manuel (amadaluzia)
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com