1940481 - Firefox shows "Firefox is being updated by another instance" if the user does not have write access to the install dir

Status: NEW

(Toolkit :: Application Update, defect)

Description

[Richard]

Attachment: Screenshot_20250108_104426.png

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

Steps to reproduce:

Uppacked firefox 134 b-zipped tarfile to /opt over existing firefox 133 installation.
sudo tar -xaf firefox-134.0.tar.bz2 -C /opt

On Ubuntu 22.04.5 LTS. Behavior is the same in Firefox on 3 different systems.

Actual results:

About Firefox shows "Firefox is being updated by another instance", when no other instance is running. Does not display whether firefox is up to date, or whether a new release is available. So cannot check from within firefox when an update becomes available.

Expected results:

About Firefox should display "Firefox is up to date". When a new release becomes available, should display "Updates available at <URL>."

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Martin Stránský [:stransky] (ni? me) (PTO, back on Jul 7)]

Do you see that if you create a new profile?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Test_Firefox_with_a_new_profile
Thanks.

Comment 3

[Richard]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #2)

Do you see that if you create a new profile?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Test_Firefox_with_a_new_profile
Thanks.

Creating a new profile, and launching the new profile in a new instance of the browser does not affect the behavior. I still see it.

Comment 4

[[e-mail]]

The same thing happens on Debian 64bit with the downloaded and extracted firefox-134.0 64bit binary release, but only for a non-admin user: all works correctly when running with elevated privileges so perhaps it's a permissions issue? The binary release is extracted into a system area that a non-admin user cannot overwrite if that makes any difference. Earlier versions did not exhibit this behaviour, so it's something in the 134.0 release.

Best regards
Paul

Comment 5

[laurent]

Same here (Linux 64bits downloaded from Mozilla.org), but when launched with --enable-updater, updates are working as intended.

Laurent.

Comment 6

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

It looks like what's happening here is: if the user running the browser can write to the install directory, the updater code creates an empty file there and locks it with fcntl to prevent other instances from trying to do the same thing (but ensuring the lock is released if the process exits for any reason). In the code this is nsProfileLock, because it was originally for preventing multiple instances from using the same profile, but in this case it's being used with the install directory. If the user can't write to the install directory, that fails… but failing because of permissions (in which case the updater wouldn't have worked at all) isn't distinguished from failing because the lock is already held, so the error message is inaccurate.

I believe this behavior was introduced in bug 1900726, and before that, on Unix platforms there wasn't anything to prevent multiple instances from trying to update at once and causing problems.

So I think the request here is for the updater to check if the install directory (or maybe XRE_UPDATE_ROOT_DIR?) is writeable, and if it's not then: don't try to take the update mutex, display a different message in the UI, and ideally also check if an update would have been possible and indicate that to the user.

(I don't normally work on the updater and I don't know much about its internals, so I hope I didn't misstate anything too badly.)

Comment 7

[Robin Steuber (she/her) [:bytesized]]

Yikes. I haven't looked through the exact code paths, but your explanation makes perfect sense so I bet you are exactly right. Technically we create the lock in the update directory, but on Linux the update directory is the installation directory. This probably affects other platforms too, it just isn't nearly as common for the update directory not to be writable on those platforms.

We need to be distinguishing between failure to lock the update directory because it's already locked and failure for other reasons. I'm gonna call this an S2 since it affects a reasonably broad category of people and the impact is potentially not updating.

Comment 8

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

:yannis, since you are the author of the regressor, bug 1900726, could you take a look?

For more information, please visit BugBot documentation.

Comment 9

[Yannis Juglaret [:yannis]]

I concur with the analysis from above. I filed related bug 1941788 where I think the fix can also solve this bug as a byproduct.

Comment 10

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

Set release status flags based on info from the regressing bug 1900726

Comment 11

[Yannis Juglaret [:yannis]]

While I still think that fixing bug 1941788 should fix this one as a byproduct, that bug is harder to solve than I thought (see the discussion there), so we might want an earlier independent fix here for severity reasons. I removed the dependency relation to reflect that.

Comment 12

[Yannis Juglaret [:yannis]]

For users impacted by this issue, here are alternate ways to know about updates:

• check our release calendar to know the dates of our planned releases;
• join [e-mail] to get notified of new releases, including unplanned releases (e.g. to fix security a security issue).

Comment 13

[Camaleon]

(In reply to Robin Steuber (she/her) [:bytesized] from comment #7)

Technically we create the lock in the update directory, but on Linux the update directory is the installation directory.

That's interesting.

As and affected user by this bug, because I always install Firefox from Mozilla's binaries (.tar.bz2) and drop install files under «/opt/firefox/*» I wonder if there could be a better approach other than just showing a different message in the updater routine.

I mean, just for the update files, maybe they can be placed under user's profile («/$HOME/.mozilla/firefox/*») instead being installed globally on a directory with restricted (write) permissions owned by root.

Not sure if this can be a feasible option, though.

Comment 14

[[e-mail]]

(In reply to Camaleon from comment #13)

I mean, just for the update files, maybe they can be placed under user's profile («/$HOME/.mozilla/firefox/*») instead being installed globally on a directory with restricted (write) permissions owned by root.

Not sure if this can be a feasible option, though.

Probably not given that linux is multiuser, so many people could be using firefox installed into a system area on a host at the same time with their own individual profiles, and those could be on NFS shares for example and not located on the same host.
I know this bug states ubuntu, but it appears to be more widespread issue from reading things so far.

On a similar train of thought, would something using /tmp work which should be writable for all users under just about all flavours of linux?
I notice for example that a file called /tmp/MozillaUpdateLock-{string} is created when a user starts firefox on a host, so could something to do with that or similar be a workable solution?

Best regards
Paul

Comment 15

[Camaleon]

(In reply to Yannis Juglaret [:yannis] from comment #12)

For users impacted by this issue, here are alternate ways to know about updates:

• check our release calendar to know the dates of our planned releases;
• join [e-mail] to get notified of new releases, including unplanned releases (e.g. to fix security a security issue).

Well, users impacted by this issue can also run an instance of Firefox as root JUST to check-and-update the browser from there.
I have to run a local (and graphical) SSH session to get this working («ssh -X root@localhost»).
This approach still works.
In fact, is the only way to update the browser when installed site-wide, because of folder's permissions just root user can run the update routine.

Comment 16

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

Set release status flags based on info from the regressing bug 1900726

Comment 17

[[e-mail]]

still present on 137.0a1

Comment 18

[bugzilla-fromthedeep]

(In reply to Camaleon from comment #15)

(In reply to Yannis Juglaret [:yannis] from comment #12)

For users impacted by this issue, here are alternate ways to know about updates:

• check our release calendar to know the dates of our planned releases;
• join [e-mail] to get notified of new releases, including unplanned releases (e.g. to fix security a security issue).

Well, users impacted by this issue can also run an instance of Firefox as root JUST to check-and-update the browser from there.
I have to run a local (and graphical) SSH session to get this working («ssh -X root@localhost»).
This approach still works.
In fact, is the only way to update the browser when installed site-wide, because of folder's permissions just root user can run the update routine.

This is not true. I run firefox from a folder that is user-readable and user-writable, and with respect to firefox updating, I still get the "firefox is being updated by another instance" message.

Comment 19

[[e-mail]]

still occurs on 137.0a1

Comment 20

[bugzilla-fromthedeep]

bug disappeared for me after I rebooted. Another "did you try turning it on and off again", lol.

Comment 21

[Camaleon]

(In reply to bugzilla-fromthedeep from comment #18)

(In reply to Camaleon from comment #15)

(...)

Well, users impacted by this issue can also run an instance of Firefox as root JUST to check-and-update the browser from there.
I have to run a local (and graphical) SSH session to get this working («ssh -X root@localhost»).
This approach still works.
In fact, is the only way to update the browser when installed site-wide, because of folder's permissions just root user can run the update routine.

This is not true.

Just to clarify, kindly expand a bit what do you think «is not true» in the statement above.

I run firefox from a folder that is user-readable and user-writable, and with respect to firefox updating, I still get the "firefox is being updated by another instance" message.

That's neither related nor connected to my comment...

Comment 22

[Jdelic]

How does this resolution make sense? Firefox could check for updates and alert the user. In my case, the user does have root access (it's my own machine), but obviously Firefox should not be installed as a user-writable binary. The update should be done by root through either a trusted channel or by running the updater as root. Forcing an insecure installation to use functionality that worked perfectly fine before 134.0 makes absolutely no sense to me, nor does the "design decision" to unilaterally force per-user, user-writable installations.

This should be revisited.

Comment 23

[Jdelic]

(In reply to Jdelic from comment #22)

How does this resolution make sense? Firefox could check for updates and alert the user. In my case, the user does have root access (it's my own machine), but obviously Firefox should not be installed as a user-writable binary. The update should be done by root through either a trusted channel or by running the updater as root. Forcing an insecure installation to use functionality that worked perfectly fine before 134.0 makes absolutely no sense to me, nor does the "design decision" to unilaterally force per-user, user-writable installations.

This should be revisited.

Sorry, I had a brainfart moment there. I misread the status update. This ticket is still open. I'm eating my hat as we speak. (hard facepalm to face initiated)

Comment 24

[[e-mail]]

I'd like to clarify what irritated me about this issue... For the longest time, my procedure was to:

• check for and download the most recent Nightly
• switch to root and install it
  Based on a previous comment, I started FF as root from where I was able to update my installation directly. Now, I'm faced with 2 options, neither of which I like:

1. As a non-root user: a) get "Firefox is being updated by another instance", which b) reminds me to download from https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly; c) update via root as before.
2. As root: a) open FF; b) Help->About Nightly->Restart to Update Nightly; done

What was wrong with allowing the non-root user to access/download the update without "Firefox is being updated by another instance" as we've been doing for so long? While option 2 above may seem more seamless, there are reasons why we don't run applications as root.

Option 1 worked satisfactorily for a LONG time. Seems to me whoever made the decision to claim "Firefox is being updated by another instance" (not true!) is a Windows person who thinks "Run as Administrator" can be translated into a Linux environment -- it sorta can if FF wants to ask for permission (password) to allow updating the binaries as root or sudo. However, many of us will not trust applications which try to bypass our security through blind faith.

Please! Just restore the old ability to a) Check for Updates and b) download them -- nothing more, nothing less. It's our decision to deal with having to install the new image as root. It's not as convenient as on Windows; but that's the price we choose to pay daily for not running Windows. From my perspective, allowing the non-root user to download the latest image as was allowed previously is NOT a valid reason to falsely claim "Firefox is being updated by another instance".

Thanks for restoring our previously available choice. Some may be OK with running FF as root; but I for one, am not.

Comment 25

[Richard]

As the originator of the original bug report, I'd just like to clarify what I'm asking for. I run the stable version of Firefox as an ordinary user on Ubuntu Linux. I never have, and never shall, run any web browser as root. There's dangerous, and there's no need. I do not need nor want the browser to update itself (an aberrent notion in Linux anyway). For security, I extract the bzipped tar file to a non-user writable location (/opt), so I update the browser with root privileges. I do that by running a bash update script using sudo. All I want is the ability, as an ordinary user, to have Firefox check for an available update. When an update becomes available, I'll shut down the browser, download the new bzipped tar file, and extract it. This used to work for years without issue. Why is it an issue now?

Comment 26

[Gian-Carlo Pascutto [:gcp]]

This was regressed by a fix that was needed to prevent Firefox updates corrupting themselves. So that's why the change was needed, the original bug could completely wreck an install. As described in comment 7, we understand the fallout is also annoying, so the bug is already marked high severity.

Comment 27

[[e-mail]]

wontfix...

How about just un-breaking it..?
At minimum, change the untrue error message.

Comment 28

[(PTO June 19-July 7) Ryan VanderMeulen]

That change was only for specific versions based on the realities of where they are in their lifecycle. The bug itself remains open and we still intend to fix it.