1559368 - Firefox doesn't handle the X server named socket (but not the directory) being nonexistent or inaccessible

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect, P3)

Description

[Robert]

Attachment: Screenshot from 2019-06-13 16-02-28.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

• Login to Linux desktop as user1
• Open a terminal
• Allow user2 to connect to your xserver: xhost +si:localuser:user2
• Start Firefox as another user: sudo -u user2 firefox OR su user2 - firefox
• Firefox displays the "Restart required" message each time it's started, browsing is not possible

Actual results:

The message "Sorry. We just need to do one small thing to keep going." is displayed every time, requiring a restart. Restarting Firefox does not help and displays the message again

Expected results:

Firefox should launch normal, just as when the user is logged into the Desktop

Comment 1

[Robert]

My system:
Linux, 64bit, Arch Linux, Gnome Desktop, Wayland + xwayland
Two desktop users who can start and run Firefox

I've tried these Firefox versions:
Firefox 66.0.5 9 (new user profile)
Firefox 67.0.2 (current and new user profile)
Firefox Beta 68.0b9 (new user profile)

Starting and using other desktop applications (like gedit or chromium) as another user works.

I am using this method to start Firefox for another user on a regular basis. Therefore I assume that this bug has been introduced recently and after the restart message has been introduced. I remember that for some time the restart button just quit Firefox instead of restarting it.

This bug was opened after I asked on reddit: https://www.reddit.com/r/firefox/comments/c06b8a/restart_required_every_single_time_firefox_starts/

Comment 2

[Robert]

As a workaround I started using ssh with x forwarding: ssh -X user2@localhost; firefox
However, this is affected as well when the browser is kept idle for some time. After ~30min-1h the "Restart required" message is displayed.

Note that Firefox is not being updated in the background. The message is never displayed for user1.

Comment 3

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Thank you for your report.

Resolving as a duplicate of bug 1559393 (though this was filed earlier) because the later bug has a bit more debugging info attached.

Comment 4

[Robert]

(In reply to Emma Humphries, Bugmaster ☕️🎸🧞‍♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #3)

Thank you for your report.

Resolving as a duplicate of bug 1559393 (though this was filed earlier) because the later bug has a bit more debugging info attached.

*** This bug has been marked as a duplicate of bug 1559393 ***

I don't think these two bugs are related.

The other bug is just about the Restart button in the About dialog of Windows and Firefox own update mechanism.

This bug is about Firefox being completely unusable when starting another users Firefox inside the current users desktop. This is something that's not possible under Windows afaik. The screenshot I posted is the new tab page.

Comment 5

[Robert Strong (they/them - no direct email)]

It isn't though there are bugs that are for the same issue. Also, afaik we don't support running Firefox using sudo.

Comment 6

[Robert]

(In reply to Robert Strong (Robert they/them) [:rstrong] (use needinfo to contact me) from comment #5)

It isn't though there are bugs that are for the same issue. Also, afaik we don't support running Firefox using sudo.

That's good to know. Using sudo -u to start Firefox as another unprivileged user has been working till now.

Using ssh -X the restart issue doesn't happen right away then the browser is launched, but only after some time.

Comment 7

[Robert Strong (they/them - no direct email)]

There are several cases where sudo won't work depending on what is going on in the code so yes, it works most of the time but there are several areas of the code where it doesn't and app update is one of them.

Comment 8

[Robert]

Okay. But I'm not using the update mechanism of Firefox. Updates are handled by the package manager (as root).

Or are you saying that this bug has been triggered by a package manger update to Firefox while it's running with sudo -u?

Comment 9

[Robert]

Attachment: ipc-error.log

Comment 10

[Robert Strong (they/them - no direct email)]

I'm saying we don't support running with sudo last I checked.

I highly suspect that the package manager updated Firefox while Firefox is running and I've seen that reported in a bug comment for the general issue which also affects app update and doesn't require sudo.

Comment 11

[Robert]

(In reply to Robert Strong (Robert they/them) [:rstrong] (use needinfo to contact me) from comment #10)

I highly suspect that the package manager updated Firefox while Firefox is running [...]

Yes, that's probably what happened.

Comment 12

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

sudo to another nonprivileged user is allowed.

The main failure mode we're trying to avoid there is running as root with a normal user's environment ($HOME, etc.) and creating root-owned files in the browser profile directory (or similar) that can't be accessed when later running as that user. With two nonprivileged users, the breakage should be more immediate (starting with the wrong user's ~/.mozilla being mode 0700), so the check is skipped.

Comment 13

[Robert]

Attachment: long-error.log

Although an error "cannot open display" is preset, the Firefox Window itself is displayed normally

Comment 14

[Robert]

The issue does not occur with Xorg (Gnome, KDE). I'm encountering the problem with Wayland + XWayland (Gnome, Weston) but not Wayland under KDE (possibly due to KDEs not yet completed Wayland implementation)

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jld, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 16

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

I think I know part of what's going on here: the cannot open display: :0 is from the content processes trying to start — note that they reference pids that aren't the one in the parent process's log messages — and it's probably failing because of sandboxing. Specifically, this can happen if the X server can't be contacted via the traditional Unix-domain socket in /tmp/.X11-unix, and the sandbox is blocking the Linux-specific “abstract address” sockets by running content processes in their own network namespaces We have some code to try to detect cases like this (with explanatory comments).

So, questions:

1. Does setting the environment variable MOZ_ASSUME_USER_NS=0 work around the problem?
2. If so, does /tmp/.X11-unix/X0 exist in the sudo session? (There's already code to check for the directory, but not whether there's anything in it.)
3. If it does, then is there anything else that might be interfering, like AppArmor policies? (Those will log to dmesg when they reject things, I think.)

Comment 17

[Robert]

1. Setting MOZ_ASSUME_USER_NS=0 works. Firefox does not show the Restart required message anymore.
   I had to add it to my sudo config using visudo in order to prevent the variable from beeing sanitized:
   Defaults env_keep += MOZ_ASSUME_USER_NS

2. The folder /tmp/.X11-unix exists and contains two files (sockets): X0 owned by user1 and X1024 owned by user gdm.
   I added write permission for user2 to /tmp/.X11-unix/X0 which makes Firefox work without setting MOZ_ASSUME_USER_NS.

3. AppArmor is active, however nothing is logged to dmesg. Disabling AppArmor at boot using the kernel parameter doesn't change anything.
   The only thing that I can think of is a side effect of running Wayland + Xwayland and therefore some stricter security model.

I hope I answered all questions sufficiently. Let me know if you need more info and thanks for finding a workaround

Comment 18

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Thanks for the info. I think I've found the rest of what's going on: the regular Xorg server creates the sockets with mode 0777, but Xwayland seems to follow the umask, so the socket typically won't have write permissions for the other user.

Which is weird, because I thought Xorg and Xwayland were built from the same code except for the backend, and that the sockets were created by this code, which does umask(0), but maybe not.

I'll file a bug with the xorg project.

Comment 19

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

It turns out there's another variation of this problem, when the directory exists but the specific server's socket doesn't; see bug 1565972 (which I'm going to duplicate onto this because the fix/workaround is the same).

I haven't gotten around to filing a bug with xorg about the socket permissions yet; if someone else wants to take care of that I won't complain.

Comment 21

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: Bug 1559368 - When determining sandbox capabilities, check for the specific X11 socket that would be used.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/89b42e05fd31
When determining sandbox capabilities, check for the specific X11 socket that would be used. r=gcp

Comment 23

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/89b42e05fd31