Dear Maintainer,

I updated my sid system and can no longer log in. I use gdm3 with the
default GNOME wayland based session. After I enter my password or used
the fingerprint sensor I got kicked right back to the login prompt.

I looked through logs and saw this kind of thing:
Jan 14 08:36:37 frau gnome-shell[3175]: Failed to start X Wayland: Wrong ownership for directory "/tmp/.X11-unix", owned by 60578 but should be same as /tmp (owned by (0)) or 1000
Jan 14 08:36:37 frau gnome-shell[3175]: == Stack trace for context 0x558653b20710 ==
Jan 14 08:36:37 frau systemd[2430]: org.gnome.Shell@wayland.service: Main process exited, code=killed, status=5/TRAP
Jan 14 08:36:37 frau systemd[2430]: org.gnome.Shell@wayland.service: Failed with result 'signal'.
Jan 14 08:36:37 frau systemd[2430]: Failed to start org.gnome.Shell@wayland.service - GNOME Shell on Wayland.

When I looked, indeed /tmp/.X11-unix is owned by the gdm greeter user
and there are two unix domain sockets owned by the gdm greeter user, and
an instance of Xwayland running as that user.

After some hackery I was able to run xlsclients against the two display
sockets and they just show:
  frau  ibus-x11
  frau  mutter-x11-frames
Using xprop I determined that they're from programs of the same name
under /usr/lib/libexec/, running as the gdm greeter user.

I can mitigate this by running the following as root from a virtual
console after I boot:
  chown root:root /tmp/.X11-unix
  chmod a+w /tmp/.X11-unix
and then everything works fine. But this isn't ideal for me, or anyone
else in the same situation.

I'm not sure what's changed - whether there's always been an Xwayland
server running in the gdm greeter session, or whether the way it's
launched as changed or what.

FYI, my xwayland package version is 2:24.1.9-1
since that might be relevant and it's not a dependency of gdm3 so not
shown below.

Control: tags -1 + moreinfo

That directory should have been created early in the boot with correct
ownership and permissions by /usr/lib/tmpfiles.d/x11.conf, which is part
of the systemd package. Is that not happening on your system?

What is the output of "systemd-tmpfiles --boot --dry-run --create" and
"systemd-tmpfiles --tldr"?

Are there any errors logged in the systemd Journal before gdm starts?
Specifically, the relevant part of the log is what's between

     Starting systemd-tmpfiles-setup.service - Create System Files and Directories...

and

     Finished systemd-tmpfiles-setup.service - Create System Files and Directories.

As a result of #1120032, you should see at least one message "Duplicate line
for path "/run/lock", ignoring", and possibly more.

If the overall system is working as intended, by the time gdm starts,
those directories should already exist, therefore the gdm greeter should
not be able to create them owned by itself, even if it wanted to.

     smcv