[SRU] gnome-shell crashed with SIGTRAP in meta_wayland_compositor_new() from meta_context_start() from main() ["Failed to start X Wayland: Directory \"/tmp/.X11-unix\" is not writable"]

[errors.ubuntu.com bug bridge]

If you are hitting this bug, please write your case in https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3984.

[Impact]

This causes one of the top Gnome-Shell crashes as caught by Ubuntu error tracker.

It happens when /tmp/.X11-unix is accessible by the user but does not pass a stricter permission check Mutter makes.

In the typical Ubuntu setup, both /tmp and /tmp/.X11-unix are root:root rwxrwxrwt, so it passes that stricter permission check.

[Test case]

1. Stop GDM:

  systemctl stop gdm

This will bring you to the virtual console (i.e. without a graphical environment, only command-line).

2. Install mutter, gir1.2-mutter-15, libmutter-15-0, mutter-common, mutter-common-bin from proposed (the exact steps to enable proposed are laid down by the SRU bot comment to this bug).

3. Execute:

  chmod 1007 /tmp/.X11-unix

4. Execute:

  MUTTER_DEBUG=all G_DEBUG=1 dbus-run-session -- gnome-shell --display-server --wayland &>log

Gnome-Shell must start and Mutter (you can look for them in 'ps aux' output if you are not acquainted with the looks of those pieces of software).

5. Now open xterm and kill the graphical environment by executing:

  pkill wayland

Verify that there are no mentions of the issue directory in the log, i.e. 'grep X11-unix log' returns nothing.

[Where problems could occur]

In Mutter or Gnome-Shell, particularly at launch phase. Also make sure Xorg applications behave normally (that's why xterm is included in test case), without failing to open or delays.

---------------

The Ubuntu Error Tracker has been receiving reports about a problem regarding gnome-shell. This problem was most recently seen with package version 46.0-0ubuntu5.1, the problem page at https://errors.ubuntu.com/problem/a7dbd55723a8ea326d1ccf32e31fe307151786c2 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports.
If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Nathan Teodosio (nteodosio)]

This comes from ensure_x11_unix_perms, which is determining that the /tmp/.X11-unix does not have at least permission bits 022:

--->
static gboolean
ensure_x11_unix_perms (GError **error)
{
  /* Try to detect systems on which /tmp/.X11-unix is owned by neither root nor
   * ourselves because in that case the owner can take over the socket we create
   * (symlink races are fixed in linux 800179c9b8a1). This should not be
   * possible in the first place and systems should come with some way to ensure
   * that's the case (systemd-tmpfiles, polyinstantiation …).
   *
   * That check however only works if we see the root user namespace which might
   * not be the case when running in e.g. toolbx (root and other user are all
   * mapped to overflowuid). */
  struct stat x11_tmp, tmp;

  if (lstat (X11_TMP_UNIX_DIR, &x11_tmp) != 0)
    {
      g_set_error (error, G_IO_ERROR, g_io_error_from_errno (errno),
                   "Failed to check permissions on directory \"%s\": %s",
                   X11_TMP_UNIX_DIR, g_strerror (errno));
      return FALSE;
    }

  if (lstat (TMP_UNIX_DIR, &tmp) != 0)
    {
      g_set_error (error, G_IO_ERROR, g_io_error_from_errno (errno),
                   "Failed to check permissions on directory \"%s\": %s",
                   TMP_UNIX_DIR, g_strerror (errno));
      return FALSE;
    }

  /* If the directory already exists, it should belong to the same
   * user as /tmp or belong to ourselves ...
   * (if /tmp is not owned by root or ourselves we're in deep trouble) */
  if (x11_tmp.st_uid != tmp.st_uid && x11_tmp.st_uid != getuid ())
    {
      g_set_error (error, G_IO_ERROR, G_IO_ERROR_PERMISSION_DENIED,
                   "Wrong ownership for directory \"%s\"",
                   X11_TMP_UNIX_DIR);
      return FALSE;
    }

  /* ... be writable ... */
  if ((x11_tmp.st_mode & 0022) != 0022)
    {
      g_set_error (error, G_IO_ERROR, G_IO_ERROR_PERMISSION_DENIED,
                   "Directory \"%s\" is not writable",
                   X11_TMP_UNIX_DIR);
      return FALSE;
    }
<---

So the bug is not in Mutter.

[Nathan Teodosio (nteodosio)]

In the case that /tmp is owned by ourselves and it matches 0200 but not 0022, it is still writable but it would fail with the present error.

I do not know if this is actually an intended blockage and thus the description is just not clear enough or if this is an edge case to consider.

Nor do we know whether all the reports here would be solved by allowing this scenario, namely {we are not root, /tmp is ours, /tmp/.X11-unix is at least 0200}.

[Pedro Monteiro (pedro.monteiro)]

Just to let you know, my problem was a slight different message: "Failed to start X Wayland: Wrong ownership for directory "/tmp/.X11-unix"
And the "/tmp/.X11-unix" directory had the right permissions.
Turns out the message is quite misleading in my case because the problem was actually in "/tmp" itself being owned by my user and not root.
I think at least the message should be clearer.

(https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7857)

[Nathan Teodosio (nteodosio)]

Thanks, Pedro, but without the hard facts it is difficult to ascertain whether this is a bug. Namely,

  whoami; stat /tmp /tmp/.X11-unix

[Nathan Teodosio (nteodosio)]

Proposed https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3984.

[Daniel van Vugt (vanvugt)]

Today this crash is in a tie for most common gnome-shell crash reported from oracular (on aarch64, looks like Raspberry Pi each time):

https://errors.ubuntu.com/problem/71fb5661de02aa699fcaa6c2067212e2aa004c42

[Nathan Teodosio (nteodosio)]

I just opened https://salsa.debian.org/gnome-team/gnome-shell/-/merge_requests/84.

[Nathan Teodosio (nteodosio)]

I just opened https://salsa.debian.org/gnome-team/mutter/-/merge_requests/127.

[Daniel van Vugt (vanvugt)]

Nathan, armhf rebuilds are failing repeatedly on one test case (x11-sync). Can you investigate?

https://launchpad.net/ubuntu/+source/mutter/47.0-1ubuntu6

[Nathan Teodosio (nteodosio)]

Yes, thank you for calling my attention to that.

[Nathan Teodosio (nteodosio)]

I sent off builds[1] of the previous release, 47.0-1ubuntu5 (just renamed it to
*ubuntu7 so Launchpad wouldn't complain), and it fails at x11-sync for ARM and
x64 too, so not a problem introduced by this patch.

The error is raised when trying to replace an existing Mutter:

--->
XIO: fatal IO error 9 (Bad file descriptor) on X server ":100"

      after 1617 requests (1617 known processed) with 0 events remaining.
<---

[1]https://launchpad.net/~nteodosio/+archive/ubuntu/fixes/+sourcepub/16628604/+listing-archive-extra

[Nathan Teodosio (nteodosio)]

For what it's worth, I killed my Xserver and in started mutter 47.0-1ubuntu5 so:

  startx /bin/mutter --x11 &> logmutter

I spawned a Xterm in it and ran

  mutter --x11 --replace &> logmutter2

I didn't get that crash looking but indeed the replace failed as I
got thrown back to the virtual console.

[Nathan Teodosio (nteodosio)]

Debian marked the test as flaky as well: https://salsa.debian.org/gnome-team/mutter/-/commit/208a5b04cfe0f7baae5129dd111261c3b3e735fb.

[Launchpad Janitor (janitor)]

This bug was fixed in the package mutter - 47.0-1ubuntu7

---------------
mutter (47.0-1ubuntu7) plucky; urgency=medium

  [ Nathan Pratta Teodosio ]
  * Warn if the X11 temp directory does not have the expected permission set.

  [ Simon McVittie ]
  * d/rules: Treat x11-test.sh as flaky

 -- Marco Trevisan (Treviño) <email address hidden> Wed, 20 Nov 2024 15:33:34 +0100

[Daniel van Vugt (vanvugt)]

Please add SRU documentation (https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/bug-template/)

[Timo Aaltonen (tjaalton)]

Hello errors.ubuntu.com, or anyone else affected,

Accepted mutter into oracular-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/mutter/47.0-1ubuntu4.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-oracular to verification-done-oracular. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-oracular. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Gre0 (gre0)]

Ubuntu 24.10

* Enabled -proposed and did an update with Synaptic
  - Forced Version of mutter from '47.0-1ubuntu4.1' to '47.0-1ubuntu4.2'

* Then after a reboot I could not login:

"Failed to start X Wayland: Wrong ownership for directory "/tmp/.X11-unix": 120.#012Ownership of "/tmp": 0.#012Current user: 1000."

* I could only open TTY2 by ctrl+alt+F2 and after a 'sudo chown root: /' and a reboot I could login again.

The error message: "Failed to start X Wayland: Directory "/tmp/.X11-unix" is not writable" is also gone.

[Nathan Teodosio (nteodosio)]

Thank you for your feedback, Gre0.

Can you please give context on your previous situation, i.e., were you ever hit by the bug as currently described or were you just testing the .2 update, realized you could not login anymore (I assume you could login normally in .1, right?) and traced it back to here?

What anyway bugs me is that the patch[1] in that Mutter update does not change logic pertaining to the ownership check, it just makes the error messsage more verbose. Also the ownership of / is not checked, just /tmp and /tmp/.X11-unix, can you confirm you wrote

  sudo chown root: /

correctly?

[1]http://launchpadlibrarian.net/764836919/mutter_47.0-1ubuntu4.1_47.0-1ubuntu4.2.diff.gz