Bug 394984: Elevated updates on OSX

From MozillaWiki
Jump to: navigation, search

== Warning == The information below is a draft and is superseded by https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=40044185, which describes the end-to-end solution.





Description of the problem

At present (8/2015), Firefox is installed by dragging and dropping the Firefox.app bundle from a .dmg to the a directory on the local system (typically /Applications). By doing so, the ownership of the Firefox.app bundle is set to <username>:staff with permissions drwxr-xr-x. In the event that a different admin user attempts to update Firefox, the update will fail to apply because the user does not have the necessary ownership/permissions to write to the Firefox.app bundle.

Proposed solution

  1. Write a new binary that will be used as Privileged Helper Tool on OSX. The only functionality in this binary will be to recursively set group ownership of a directory to "wheel" (aka "root" or "admin") and recursively set "write" permission for the group on said directory after proper elevation.
  2. In the event that the updater is unable to write to the Firefox.app directory (bug 394984), launch the Privileged Helper Tool.
  3. Privileged Helper Tool prompts for administrative username and password to run as root.
  4. If credentials were entered correctly, the Privileged Helper Tool will change the group ownership to "wheel" and add write permission for the group recursively on the Firefox.app bundle as follows:

<username>:wheel drwxrwxr-x

  1. If the ownership and permissions were set successfully, the regular (unelevated) update proceeds.
  2. Future updates will no longer require the Privileged Helper Tool, unless ownership and/or permissions have changed in such a way that it is needed again.

If the user was unable to enter admin credentials, or if the new ownership/permissions couldn't be set successfully, the update will fail and we will increment a counter in the user's profile. Once a threshold is hit, we will no longer attempt to stage an update and will direct the user to our website for a manual install (existing workflow).

FAQ

What's the risk of these additional permissions and/or the new group ownership if Firefox gets owned?

The new proposal calls for setting the group ownership of Firefox to "wheel" and adding "write" permission for this group. Due to the fact that:

  1. only an administrator can grant these additional permissions
  2. the additional permissions are restricted to administrators
  3. any administrator could already set these additional permissions manually
  4. most apps installed via a .pkg installer (instead of a .dmg like Firefox) already set these same permissions on their apps
  5. most users "own" Firefox.app because they installed it, so they already have rwx permissions

there shouldn't be any additional risk in the case that Firefox gets owned.

What happens when Firefox is updated?

The ownership/permissions for new or changed files should be inherited from the main Firefox.app bundle, i.e. <username>:wheel and rwxrwxr-x (for executable files) or rw-rw-r--.