Bug 253277 - x11/xtrans: Don't unlink existing UNIX sockets => allows multiple X sessions from sddm
Summary: x11/xtrans: Don't unlink existing UNIX sockets => allows multiple X sessions ...
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-x11 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-05 18:13 UTC by Olivier Certner
Modified: 2021-02-09 09:40 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (x11)


Attachments
Patch against the ports tree (1.60 KB, patch)
2021-02-05 18:13 UTC, Olivier Certner
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Certner 2021-02-05 18:13:27 UTC
Created attachment 222189 [details]
Patch against the ports tree

Patch that removes the `unlink` call before binding some UNIX socket.

The problem with the existing approach is that, when Xorg is launched as `root`, it can always unlink existing sockets, which it does when no display is explicitly specified and `-displayfd` is used.

Moreover, the X server removes the UNIX socket when exiting (even in most abnormal cases).

Typically, sddm exactly triggers the problem. So when you try to open another session through it, the first session's sockets are crushed and it becomes stale.

I'm proposing the patch here since it is not practically useful on platforms that launch Xorg with an unprivileged user and because upstream seems inactive.
Comment 1 Niclas Zeising freebsd_committer 2021-02-05 23:15:41 UTC
I am quite skeptical of pulling this in without it first being submitted and accepted upstream.
Can you explain exactly what problem you are trying to solve?
Comment 2 Olivier Certner 2021-02-08 11:24:30 UTC
Hi,

As for the high-level problem I'm fixing, I wrote this description:

> Typically, sddm exactly triggers the problem. So when you try to open
> another session through it, the first session's sockets are crushed
> and it becomes stale.

What do you find unclear in it exactly?

As for the low-level description, let me recapitulate with more context. As you most probably know, there are two ways that Xorg selects its display at startup:
- Either you supply an explicit display on the command-line (e.g., ":1").
- Or you do not, and either "-displayfd" has been specified, in which case Xorg will try to assign some automatically, or it has not, in which case :0 is used by default.
("-displayfd" has other effects, but this is a separate discussion, relevant to the other bug #253278.)

The problem is with the automatic assignment of display. It works by trying to grab the first display available (from :0 when using UNIX sockets), which it does by simply unlinking an existing socket file and then binding a new socket to the same file. When the server is run as root, this operation always succeeds, and any existing socket for :0 ("/tmp/.X11-UNIX/X0") that would exist is removed. This leaves any preexisting X session on :0 stale (e.g., launching new apps make them go to the new session).

And SDDM triggers that: It passes "-displayfd", and no display directive, relying on the server to do display assignmnent, which it doesn't do correctly.

Now, I agree that this problem is probably not FreeBSD specific (it affects platforms/distributions running Xorg as root). If you prefer, I'll report it upstream and we'll see how it goes.
Comment 3 Olivier Certner 2021-02-08 16:43:46 UTC
Amusingly, I found this code at start of 'startx':

# Automatically determine an unused $DISPLAY
d=0
while true ; do
    [ -e "/tmp/.X$d-lock" -o -S "/tmp/.X11-unix/X$d" ] || break
    d=$(($d + 1))
done
defaultdisplay=":$d"
unset d

This is exactly what the proposed change makes X (launched with '-displayfd') do.
Comment 4 Olivier Certner 2021-02-09 09:40:00 UTC
Reported upstream here:
https://gitlab.freedesktop.org/xorg/lib/libxtrans/-/issues/4