Open Bug 1957613 Opened 9 months ago Updated 1 month ago

Firefox update stuck if app permissions change on macOS

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Version:
Firefox 136
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: david, Unassigned)

References

Details

Attachments

(1 file)

lsFF.txt
16.83 KB, text/plain
Details

Steps to reproduce:

  • Download FireFox and install it manually (For testing purposes download an older version so you can test autoupdate)
  • FireFox auto downloads an update and is waiting for user to restart the app to apply the update
  • We deploy the update from MDM. We shut down the app before updating it.
  • When the user then tries to open FireFox again it will just keep prompting for credentials for "Install helper"
  • Credentials are accepted, but nothing ever happens and the Firefox process quits. (User is admin)

(Fun fact: If you delete Firefox and install the same old version again, then the installer will actually complete and install the app when you launch it right after the reinstall)

Actual results:

When the user installs Firefox the permissions look like:
drwxrwxr-x@ 3 USERNAME admin

But when MDM updates it, it will change to
drwxr-xr-x 3 root wheel

If the permissions are reset with "sudo chown -R USERNAME:staff Firefox.app" then the it will work again.

We have been seeing this for months on many different Firefox releases.

Expected results:

I expect that since the user is admin that Firefox will be able to update anyway. We are not seeing this behavior in other browsers, so I assume it can be done.

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

Component: Untriaged → Application Update
Product: Firefox → Toolkit

we're wondering why the MDM changes it to root wheel?

wheel doesn't have write access, and admin users aren't root, so they wouldn't be able to do anything either.

What are the permissions on other apps/browsers after update?

Hi Mike,

I assume the MDM changes it to root/wheel because that's what it's executing the the install as.

Google Chrome (And Microsoft Edge) updates without any issues with the same file permissions. No changes to the permissions after using auto update.

I assumed that the reason that Firefox prompts to "install a new helper tool" was to get around the permission issues. (I assume thats a launch agent?)
I can see that both Chrome and Edge installs a launch agent, but I am unable to find one for Firefox.

(In reply to David Larsen from comment #3)

Hi Mike,

I assume the MDM changes it to root/wheel because that's what it's executing the the install as.

Google Chrome (And Microsoft Edge) updates without any issues with the same file permissions. No changes to the permissions after using auto update.

I assumed that the reason that Firefox prompts to "install a new helper tool" was to get around the permission issues. (I assume thats a launch agent?)
I can see that both Chrome and Edge installs a launch agent, but I am unable to find one for Firefox.

No, the helper tool's main purpose is to fix the ownership and permissions of the Firefox.app bundle in situations where one admin user installed Firefox using the .dmg package and another user is trying to update. It will change the ownership and permissions to drwxrwxr-x 91 root admin so that any admin user can update Firefox in the future without requiring the helper tool. The reason why the updater prompts to install the helper tool in your situation is because it is a last ditch attempt to fix the ownership and permissions on the Firefox.app bundle in order for the update to succeed. However, drwxr-xr-x 3 root wheel does not allow for this to occur.

Having the MDM set the ownership and permissions to drwxrwxr-x 91 root admin should address your issue and also avoid the need for the helper tool.

Are you still experiencing this problem?

(In reply to David Larsen from comment #0)

  • We deploy the update from MDM. We shut down the app before updating it.

Are you disabling Firefox's own updater via enterprise policies? If we are launching the helper tool when the updater is disabled, that is a bug and I want to know about it. If you are updating Firefox externally but not disabling Firefox update, that is an unsupported configuration.

Flags: needinfo?(david)

I reached out to JAMF as well:

As far as that issue goes, do you know if they’ve filed a support ticket with Jamf? There’s a few different ways they could be trying to push the app/push updates (App Installers vs. Policy for example). Depending on how they’re pushing it out to computers there could be issues between the Jamf pushing of updates and auto-updates in the app if that’s enabled. Either way I’d like our support team to be able to at least log the issue with the customer and be able to provide some sort of insight from the Jamf side of things.

I see some discussion of ownership possibly playing a role in the issue, depending on how they are deploying it through Jamf there are some options to adjust those settings as well.

Either way, I think having them add that support ticket with Jamf Support would be a good first step. Or if they already have a ticket if we could get that ticket number.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:mpohle, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(david) → needinfo?(mpohle)

Bad bot. There is no harm in a needinfo asking for information that we still want from the reporter.

Flags: needinfo?(mpohle) → needinfo?(david)

Hi, sorry I must admit I forgot all about this issue again.

As a workaround we disabled Firefox autoupdates and have not seen any incidents since then.

I don't really see any value in creating a Jamf case. We are not using their built-in Jamf App Catalog to update, but instead deploying it with a policy.
All policies runs as root and that is not something that can/will change.

The only fix I see is to deploy Firefox with a .pkg that then sets the correct permissions when it installs.

Flags: needinfo?(david)

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

Are you still experiencing this problem?

(In reply to David Larsen from comment #0)

  • We deploy the update from MDM. We shut down the app before updating it.

Are you disabling Firefox's own updater via enterprise policies? If we are launching the helper tool when the updater is disabled, that is a bug and I want to know about it. If you are updating Firefox externally but not disabling Firefox update, that is an unsupported configuration.

We were indeed updating it while autoupdates were enabled. I was not aware this was unsupported, but we ended up disabling it anyway, so I guess all is good.

(In reply to Stephen A Pohl [:spohl] from comment #4)

(In reply to David Larsen from comment #3)

Hi Mike,

I assume the MDM changes it to root/wheel because that's what it's executing the the install as.

Google Chrome (And Microsoft Edge) updates without any issues with the same file permissions. No changes to the permissions after using auto update.

I assumed that the reason that Firefox prompts to "install a new helper tool" was to get around the permission issues. (I assume thats a launch agent?)
I can see that both Chrome and Edge installs a launch agent, but I am unable to find one for Firefox.

No, the helper tool's main purpose is to fix the ownership and permissions of the Firefox.app bundle in situations where one admin user installed Firefox using the .dmg package and another user is trying to update. It will change the ownership and permissions to drwxrwxr-x 91 root admin so that any admin user can update Firefox in the future without requiring the helper tool. The reason why the updater prompts to install the helper tool in your situation is because it is a last ditch attempt to fix the ownership and permissions on the Firefox.app bundle in order for the update to succeed. However, drwxr-xr-x 3 root wheel does not allow for this to occur.

Having the MDM set the ownership and permissions to drwxrwxr-x 91 root admin should address your issue and also avoid the need for the helper tool.

New discovery:

So for testing until now I compared the permissions of the app from the DMG you provide with what we install from Jamf.
Unfortunately i did not know that you also provide pkg installer, which is what we deploy from Jamf (It is automated with AutoPkg, so I was not aware of this).

The official Firefox pkg installer gives the Firefox.app the "drwxr-xr-x 3 root wheel" permissions, not Jamf.

Sorry for the confusion.

Hi Stephen, it looks like there is an inconsistency in permissions between the .dmg and the .pkg. Is this expected behavior?

Flags: needinfo?(spohl.mozilla.bugs)

(In reply to Max Christian Pohle [:/dev/max] from comment #12)

Hi Stephen, it looks like there is an inconsistency in permissions between the .dmg and the .pkg. Is this expected behavior?

Forwarding to Robin who has the most up to date knowledge here. What do we expect the ownership and permissions to be when installing Firefox using the .pkg?

Flags: needinfo?(spohl.mozilla.bugs) → needinfo?(bytesized)

Ugh, something awful that isn't what the dmg does. I don't remember specifically and I don't currently have my macbook handy. root:wheel sounds right.

Flags: needinfo?(bytesized)

Thinking about this some more, root:wheel ownership with drwxr-xr-x permissions should still allow for the privileged helper tool to fix the ownership/permissions. So the fact that the privileged helper tool is seemingly unable to do so makes me suspect that something else might be going on here.

Could you run ls -alR /Applications/Firefox.app (or whichever path is causing the issue) in Terminal and attach the results?

It sounds like you have successful updates via Jamf now, which hopefully addresses the most immediate concern here.

Attached file lsFF.txt —

I have attached the output as "lsFF.txt".

And yes, we do have the updates working from Jamf, but I still had a user reach out yesterday, as he experienced the original issue again.

I can't see anything obviously wrong here. As a next step I would suggest to manually set ownership to root:wheel on a Firefox install (or install via .pkg) and let it run through an update to see if this can be reproduced. I'll defer to the app update team for this as I wouldn't be able to get to this in the short term.

I did some tests now and the permissions from the pkg really does not make sense.

Example:

  1. Install FF 137.0 from pkg - permissions are now drwxr-xr-x 10 root wheel
  2. Start FF and start the updater
  3. Restart FF to apply update
  4. Update does not apply, but the prompt to fix permissions appear
  5. Click update and restart again
  6. FF now successfully updates to newest version AND changes the permissions to drwxrwxr-x 11 root admin

A pkg allows you to set the permissions on the installed files, so it really makes no sense that it sets root/wheel and then fixes it afterwards.

We have started getting an increasing number of tickets regarding Firefox asking for permissions on startup and despite an admin user entering their password, the prompt just appears again and again. Unfortunately I'm getting the reports from remote techs and don't have direct access to the afflicted machines for troubleshooting.

Is the reason for prompting and the result of whatever action it is that fails logged anywhere?

Logs should be left in the updates subdirectory of the Update folder, which can be located via about:support.

This bug was posted in the macadmins Firefox slack as we just ran across it here (we install FF using Munki and it installs as "root:wheel" as well because of that.

However, we found that the updater works if you have clicked "Allow" in the "find devices on local networks" prompt for "Firefox Software Update" -- but does not work (ie, loops) if you have clicked "Don't Allow".

I'm not sure if that will help here, but we are able to reproduce this behavior of the updater looping depending on which option the user has selected for that dialog box. (We also noticed that no matter which option you select, there is no Firefox application listed under "Privacy & Security -- Local Network" in the System Settings, too...)

(In reply to Steve Maser from comment #21)

This bug was posted in the macadmins Firefox slack as we just ran across it here (we install FF using Munki and it installs as "root:wheel" as well because of that.

However, we found that the updater works if you have clicked "Allow" in the "find devices on local networks" prompt for "Firefox Software Update" -- but does not work (ie, loops) if you have clicked "Don't Allow".

I'm not sure if that will help here, but we are able to reproduce this behavior of the updater looping depending on which option the user has selected for that dialog box. (We also noticed that no matter which option you select, there is no Firefox application listed under "Privacy & Security -- Local Network" in the System Settings, too...)

I can confirm that I can replicate that the Helper Tool actually works if you have clicked "Allow" in the "find devices on local networks" prompt for "Firefox Software Update". The local network prompt only appeared after I had enabled "find devices on local networks" while Firefox was in a working state.
I do see it listed under Privacy & Security though, so not sure why it's missing for you.

See also bug 1971620

Triggering an unexpected prompt that must be accepted to update potentially for all users using macOS elevated update seems serious enough to warrant S2. This is stalled at the moment because the domain expert is busy with more pressing things (related to seeing this permission prompt in other places, IIUC). I am not a domain expert, but I think that the IPC that we use to communicate between the elevated and unelevated updater instances for some reason uses a networking protocol via localhost, which causes this permissions prompt.

Severity: -- → S2
Duplicate of this bug: 1971620

My users have installed Firefox through munki, too, and got stuck with the admin helper prompt tool. I resolved it by deleting /Users/$USER/Library/Caches/Mozilla/. I assume this was created by an automatic update check.

I also implemented a enterprise policy to prevent Firefox from checking for updates, so hopefully it will not try again.

I have been able to complete some other pending work and finally had a moment to look into this: it appears that our use of NSConnection might indeed trigger this macOS prompt. NSConnection is now deprecated and NSXPCConnection is suggested in its place. Unfortunately, I have not been able to confirm whether or not we would still be triggering this macOS prompt after switching to NSXPCConnection. Since I'll be working on the privileged helper tool for separate reasons I'll be keeping this in mind as something to try.

This maybe related to my incidents ever since I tried to upgrade my old Firefox v145 in macOS Sequoia v15.7.2 in a 13" 2020 Intel MBP.

"Firefox is trying to install a new helper tool. Enter an administrator's name and password to allow this." gets in a loop in a standard (non-administrator) macOS account. And yes, I entered my macOS administrator level login data for its install prompt to upgrade, but it kept getting stuck when retrying. I even said no and then Firefox's dock icon got stuck in bouncing up and down for a minute and then stopped. If I launch it again, then it repeats that install a new helper app tool.

I tried rebooting and logging into the same standard/non-admin macOS account to retry. Same results. I logged out and relogged in into my administrator level account, then it worked. I logged out and relogged into my standard/non-admin level account, same prompt again. This has been happening after upgrading to Firefox v145.0.0. This issue started with v145.0.1 and v145.0.2. I tried deleting Applications' Firefox app into trash, redownloading, and reinstalling Firefox (well drag app to /Applications), but that didn't help. :(

Does anyone have this problem too? I use non-admin accounts for security reasons especially when other users are not technical types.

In standard/non-admin macOS account's Terminal app, I did manage to fix it through Terminal's zsh command line: ~ % /Applications/Firefox.app/Contents/MacOS/firefox --first-startup

I was able to launch Firefox v145.0.2, but its help about told me to restart again even though it was already at v145.0.2. This time, it worked. No more install helper app prompt for now. I am sure it will be back in future version upgrades the last two minor v145 upgrades. :(

Did anyone have this problem in macOS' standard/non-admin account for Firefox upgrades?

It happened again with v146 update with non-admin macOS account. I tried renaming /Users/$USER/Library/Caches/Mozilla/ and retried. Same loop issue. I also tried: ~ % /Applications/Firefox.app/Contents/MacOS/firefox --first-startup in macOS' Terminal. Its help about told me to restart again, and it failed again. I saw a bunch of Permission Denied with /Applications/Firefox though. :(

Also, ls -all shows this for /Application/Firefox after rebooting, logging into admin level macOS account, and successfully upgrading Firefox to v146: drwxrwxr-x@ 3 ant admin 96 Dec 9 10:14 Firefox.app

I don't know if that is correct or not. I know I always had to enter my admin level account (ant) data to let Firefox update and run its installer helper thing. We'll see what happens in the next internal upgrade.

Do you have any firewall settings that might cause this (System Settings > Network > Firewall)? Or is the privileged helper tool, the app updater and/or Firefox denied local network access (System Settings > Privacy & Security > Local Network)?

Flags: needinfo?(ant)

macOS' firewall shows helper app is allowed incoming and outgoing. As for local network access, both Firefox and Firefox Software Updater was disabled. If these were the causes, then why would they need those to upgrade Firefox? I did see Firefox's internal updater download the update and told me to restart Firefox to update it.

Flags: needinfo?(ant)

See comment 27 for context, but it appears that the current use of NSConnection is triggering an OS prompt that asks for permission to grant local network connection access to the privileged helper tool. It appears that declining this permission prevents IPC to occur between the privileged helper tool and the updater, which prevents updates from succeeding.

Interesting. The helper tool needs to tell the user that local network connection access is required to upgrade Firefox. I assume older macOS versions (e.g., Ventura) didn't have this. I find interesting that Google Chrome did not have any problems with its internal updates even with Chrome's access disabled. The reason why I disabled these local network conecttion access because it doesn't make sense for web browsers to be locating and communicating with network devices. For now, I will leave it on for Firefox and see what happens in the next internal public update.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: