Moving the X11 socket to XDG_RUNTIME_DIR

[Artur Manuel]

On Fri Jul 4, 2025 at 7:33 AM BST, Carsten Haitzler wrote:
> 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...
Understood. I would think that the directory itself is world-writeable
but the symlinks wouldn't be. I think that would work over just having
it there in my opinion. Furthermore, if I recall correctly, the
filesystem would still only allow the user who owns the socket to write
to it even if the root owned the symlink. This may work differently in
other systems though.
>> > 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.
Compatibility should still be a concern, but I believe it shouldn't be
priority was what I was saying. Other than that, I think it should be
fine to symlink the socket, as it would probably allow only you (and
root) to read and write to the socket. I would probably do it backwards
where we symlink the socket to XDG_RUNTIME_DIR but state that behaviour
will change to deprecate /tmp/.X11-unix so that maintainers have enough
time to move 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. :)
Indeed, this is very likely an issue that would need to be resolved.
That is why I'm thinking of symlinking it at the start and then
deprecating it eventually. We shouldn't move extremely quickly about it
but slow enough to where everyone has enough time to migrate.

I have an idea related to post-deprecation which would probably be
useful. My idea is that when an X11 session is created, it creates a
"lock file" in /var/tmp/X11/:$DISPLAY and when a session is deleted, it
deletes the corresponding file. This lock file isn't itself a socket but
rather an empty file to indicate a session exists. I'd be happy to
further discuss this if you are interested.

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

Cheers,
-- 
Artur Manuel (amadaluzia)