1349649 - Firefox ESR 52.0 Requires Administrative Rights to Install version 52.0.1

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, defect)

Description

[syost]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3; rv:11.0) like Gecko

Steps to reproduce:

Deployed Firefox ESR 52.0 to MacBook Test lab, and set the software to Auto-update. Waited for a new version of ESR to release. 


Actual results:

Version 52.0.1 downloaded anonymously without any user interaction, but upon restart of Firefox it prompted the user to update and admin credentials. Prompt said it was installing the Firefox "Helper" Application.


Expected results:

It should have installed updates silently on application restart without ANY user interaction. We are deploying this software to roughly 100 Macbooks, and do not want the users to have their workflow interrupted by asking to elevate to install the latest version of Firefox. Also our users do not have admin rights, so they would need to call local IT.

Comment 1

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

If the user doesn't have permissions to all of the bundle it will prompt a few times before giving up now that bug 394984 is fixed. Also, there have been cases where the bundles permissions can be changed outside of Firefox such as an OS upgrade.

Could you check the permissions of all of the files in the bundle and post the results in this bug?

Comment 2

[syost]

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #1)
> If the user doesn't have permissions to all of the bundle it will prompt a
> few times before giving up now that bug 394984 is fixed. Also, there have
> been cases where the bundles permissions can be changed outside of Firefox
> such as an OS upgrade.
> 
> Could you check the permissions of all of the files in the bundle and post
> the results in this bug?

Based on my investigation, all the files in the Firefox.app are only writeable by system. Everyone and Admin only have read permissions. I could probably swing it with chmod to allow write from user to the bundle, but that does not cover the base where an OS X upgrade re-writes the permissions.

Comment 3

[Stephen A Pohl [:spohl]]

Based on your bug description it seems like you're trying to allow any non-admin user to update Firefox. You will have to think about the workflow to keep this secure. The usual flow is this:

1. User A downloads Firefox and drags it to a location that he has write access to.
2. Firefox is owned by user A and therefore he has write access to it for updates.
3. Other non-admin users cannot update Firefox.

Elevated OSX updates allow for the following workflow:

1. User A downloads Firefox and drags it to a location that he has write access to.
2. Firefox is owned by user A and therefore he has write access to it for updates.
3. A different user B with admin credentials attempts to update Firefox.
4. User B is prompted for admin credentials.
5. If admin credentials are valid, Firefox chmods permissions to make Firefox writable to all admin users.
6. Any admin user can now update Firefox without being prompted anymore.

There is no built-in support for updates by any non-admin user. Simply chmod-ing Firefox to make it writable to all users is not a secure solution.

Comment 4

[Stephen A Pohl [:spohl]]

Robert, this could be morphed into a bug to offer a type of daemon for OSX that would do the same as the service on Windows. A daemon (running with admin privileges) could support updates in the background for non-admin users. I'm not sure if there is already a bug for this. I'll let you make the call here. To state the obvious: this would be a sizeable amount of work.

Comment 5

[Stephen A Pohl [:spohl]]

Accidentally closed this. Reopening.

Comment 6

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

We're not going to create a daemon for Mac OS X in the foreseeable future so closing as wontfix. This doesn't mean we won't ever create one but since there is no plan to create one it is better to close this bug out