1648642 - policies.json doesn't work if GPO aren't able to be read

Status: RESOLVED FIXED

(Firefox :: Enterprise Policies, defect, P3)

Description

[Ricardo Gonçalves]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

Created policies.json file with a sample payload.
Ran Firefox from a guest account on Windows 7 SP1.

Actual results:

Firefox doesn't recognize that there are any enterprise policies, according to about:options and about:policies. about:config does show that there is an error, but when the link is followed through, it redirects to the about:policies page, that doesn't report an error.

Expected results:

The policies described on policies.json should have been applied, since I don't have any Group Policy Objects enabled.

I recently had to remove the GPO's Avast put in HKLH/Software/Policies in order to make policies.json work on an admin account. Given that I was running Firefox from a guest account, and guest accounts are somewhat weird in regards to any number of stuff, I decided to check the previous registry key, which I was unable to do, because the guest account doesn't have (for some reason) read access to that key.
Giving the guest account read access to the registry key allows Firefox to correctly identify that there are no GPO and fallback on policies.json.
Here is where I think the bug exists: if Firefox is unable to check for GPO existence, it should fallback to policies.json if it exists.

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Mike Kaply [:mkaply]]

about:config does show that there is an error

Can you provide more detail or screenshots on what you mean here?

Are there any errors on the Javascript console?

Where exactly did you place policies.json?

Can you set browser.policies.loglevel to debug in about:config and see if there are any additional errors on the console?

Comment 3

[Ricardo Gonçalves]

Attachment: 0001.PNG

Comment 4

[Ricardo Gonçalves]

Comment on attachment 9159895 [details]
0001.PNG

I have another 13 images detailing what I did, however I can't seem to find a good way to mass upload images. I'm currently writing my method and results and if there is no good way to upload, I'm opting to send a zipped archive with them.

Comment 5

[Ricardo Gonçalves]

policies.json is on C:\Program Files\Mozilla Firefox\distribution, as indicated by the available online resources about Enterprise Policies, and it's a standard UTF-8 file (as I found out, saving Unicode with regular Notepad saves with a format Firefox didn't recognize, but I digress).

In order to make a coherent sequence, I'm now redoing more or less what I found out that lead to the bug. Hence, I've denied the guest account permission to read HKLM/Software/Policies. I've also added the browser.policies.loglevel config to debug, and enabled the browser console. Under these conditions, here are the following screenshots.

(Check screenshots 0001 to 0006)

Things to note are the NS_ERROR_FAILURE at the start (which I believe refers to the HKEY_LOCAL_MACHINE line), without doing anything else, and the Exceptions at the bottom, which appeared after checing about:options.
Checking about:support now and pressing on the error link now does show errors on the about:policies page, specifically:

• root = HKEY_CURRENT_USER
• root = HKEY_LOCAL_MACHINE

The "Can't find profile" error I don't think is related, as it appeared after opening a private window and I can also see it when I fix this.

Removing the browser.policies.loglevel config also removes the messages on about:policies#errors. (as shown on screenshot 0007)

Reinstating the browser.policies.loglevel config and giving the guest account read access to the registry key gives this.

(check screenshots 0011 to 0016)

So, the NS_ERROR_FAILURE at start disappears, but there is still a pair of exceptions that happen only on the first time I check the about:options page.
Everything else seems to be OK, with the odd thing that in about:policies, there are the same errors as before, but now the policies I set up on policies.json are up. For reference, here are the contents of the policies.json file:

{ "policies": { "AppUpdateURL": "http://localhost:7999", "DisableAppUpdate": true } }

Comment 6

[Ricardo Gonçalves]

Attachment: The collection of all screenshots relevant to the first request for information

Comment 7

[Mike Kaply [:mkaply]]

Thank you for all this detail, it helped a lot. I was able to confirm this by causing opening the key to fail in _readData which causes the policies.json not to be read.

Comment 8

[Mike Kaply [:mkaply]]

Attachment: Bug 1648642 - Handle registry errors gracefully. r?mconley

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7200286a8dab
Handle registry errors gracefully. r=mconley

Comment 10

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/7200286a8dab

Comment 11

[Mike Kaply [:mkaply]]

Comment on attachment 9160203 [details]
Bug 1648642 - Handle registry errors gracefully. r?mconley

Beta/Release Uplift Approval Request

• User impact if declined: Cases where registry is readonly causes policy to read incorrectly.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce: Difficult to reproduce due to changes needed to registry. Also can't automate test because we can't do registry in our test suite. I tested by making changes in code.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Policy only, handles error case.
• String changes made/needed:

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Policy only.
• User impact if declined: Cases where registry is readonly causes policy to read incorrectly.
• Fix Landed on Version: 80
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Policy only.
• String or UUID changes made by this patch:

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9160203 [details]
Bug 1648642 - Handle registry errors gracefully. r?mconley

Approved for 79.0b8 and 78.1esr.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/15188f16f5fb

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/0e15c3395547