Open Bug 1367100 Opened 8 years ago Updated 3 years ago

Firefox should create an empty NativeMessagingHosts folder

Categories

(WebExtensions :: General, enhancement, P3)

53 Branch
enhancement

Tracking

(Not tracked)

REOPENED

People

(Reporter: jamie, Unassigned)

Details

(Whiteboard: [dev-ux])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/604.1.22 (KHTML, like Gecko) Version/10.2 Safari/604.1.22 Steps to reproduce: 1. Install and launch Firefox 2. Open ~/Library/Application Support/Mozilla Actual results: No NativeMessagingHosts folder Expected results: See empty NativeMessagingHosts folder
If the first Native Messaging application that is installed creates the NativeMessagingHosts folder as part of an installer that runs with escalated privileges, it will create it as owned by root:staff with 755 permissions. As a result, other apps that may need to install a Native Messaging Host manifest JSON file are blocked from writing to the folder without also requesting escalated privileges. If Firefox were to create this folder with the proper privileges from the start, then installers would be less likely to erroneously assign its ownership. I have also filed the same request in the Chromium project as well: https://bugs.chromium.org/p/chromium/issues/detail?id=725513
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
This is a bug that should be fixed in those installers. As a rule, we don't create empty directories before they're needed.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
(In reply to Kris Maglione [:kmag] from comment #2) > This is a bug that should be fixed in those installers. As a rule, we don't > create empty directories before they're needed. I know this bug is closed, but I'd ask you to reconsider. For a NMH folder created with incorrect permissions, it creates confusion by distancing the issue's manifestation from its cause and puts the onus for fixing the permissions on the user, which can be a daunting task for non-technical users. Chrome is taking the approach of creating the empty folder: https://bugs.chromium.org/p/chromium/issues/detail?id=725513 Doing so makes the user experience much better for all users of NM-capable extensions.
Here's another argument in favor of creating this folder: the Mac App Store. In order to have an app in the Mac App Store, it must be sandboxed. This means no file access to most of the system, but in some cases, Apple will grant exceptions for well-reasoned use cases. If the folder does not already exist on disk, an exception for ~/Library/Application Support/Mozilla/NativeMessagingHosts will not allow the app to create the folder. The app could only do so by having an exception for the whole Mozilla Application Support folder, which is a terrible idea and something Apple is not likely to grant. By creating the folder up front, you make it easier for developers with apps in the Mac App Store to support Firefox with a good user experience.
Comment 4 sounds like a good reason to me.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
This doesn't sound so great to me, does this mean you won't install the native messaging manifest if the NativeMessagingHosts directory does not exist? This means that if I have a fresh user account (e.g., I'm setting up a brand new machine) then if I install 1Password before installing Firefox, the 1Password extension won't work..
Severity: normal → enhancement
Priority: -- → P3
Product: Toolkit → WebExtensions
(In reply to Andrew Swan [:aswan] (on PTO until 7/23) from comment #6) > This doesn't sound so great to me, does this mean you won't install the > native messaging manifest if the NativeMessagingHosts directory does not > exist? It is not that we won't install it but that we _can't_ install it due to macOS sandboxing. With the release of 1Password 7, both the direct and Mac App Store releases are sandboxed, so we are restricted in which directories we have access to. Specifically, we can write to the NativeMessagingHosts folder if it exists, but we cannot create it if it is not present. > This means that if I have a fresh user account (e.g., I'm setting up > a brand new machine) then if I install 1Password before installing Firefox, > the 1Password extension won't work.. I don't think this would be limited to a fresh user account. Under sandboxing, here is what will happen if Firefox does not create the folder: * User has 1Password installed * User has Firefox installed * User has installed the 1Password add-on in Firefox 1Password wants to create the native message host manifest JSON and looks for the folder at the expected location using system APIs (~/Library/Application Support/Mozilla/NativeMessagingHosts). If this folder exists, the sandbox entitlements exception will allow us to create the file and the extension will connect. If this folder does not exist, 1Password watches for it to be created and when it is created the monitor will trigger 1Password to create the manifest file. But until the NativeMessagingHosts folder exists, we will not be able to write the file necessary for the 1Password add-on to connect to the native application.
Sorry for the noise, but one of our Mac developers corrected my understanding. 1Password attempts to create the file when the 1Password extension helper starts but is not able to monitor the directory for creation. As such, 1Password would need to be fully quit and restarted once the directory is created.
Component: Untriaged → General
Whiteboard: [dev-ux]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.