1574963 - Disable profile per channel/directory for the ESR

Status: VERIFIED FIXED

(Toolkit :: Startup and Profile System, task, P2)

Description

[Mike Kaply [:mkaply]]

We were waiting for some input from enterprises that started deploying the ESR before deciding if we should turn off profile per install.

Based on experiences in this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1572789

and comments on the enterprise list, I believe we should turn off this feature for the ESR until we have solved of these issues.

The main issues seem to be:

1. default profile gets renamed to default-esr
2. Two profiles are always created (default and default-esr)
3. Migration from 32 to 64 bit (where 32 bit is uninstalled) causes a new profile (Program Files (x86) to Program Files

There are also unknown issues happen on Mac as well.

Comment 1

[Dave Townsend [:mossop]]

(In reply to Mike Kaply [:mkaply] from comment #0)

We were waiting for some input from enterprises that started deploying the ESR before deciding if we should turn off profile per install.

Based on experiences in this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1572789

and comments on the enterprise list, I believe we should turn off this feature for the ESR until we have solved of these issues.

The main issues seem to be:

1. default profile gets renamed to default-esr

Just to be clear, no profiles get renamed as a part of this feature. What is happening in bug 1572789 is that Firefox decides not to use an existing profile and instead creates a new one for use.

2. Two profiles are always created (default and default-esr)

This is required in order to avoid cases of downgrading to pre-67 builds of Firefox.

Comment 2

[Mike Kaply [:mkaply]]

Just to be clear, no profiles get renamed as a part of this feature. What is happening in bug 1572789 is that Firefox decides not to use an existing profile and instead creates a new one for use.

I phrased that poorly. I'm referring to the behavior that if on the ESR, the default profile is no longer called default, it's called default-esr, but there is an empty profile that uses the old name default.

This is creating problems for existing scripts and automation.

Comment 3

[Mike Kaply [:mkaply]]

[Tracking Requested - why for this release]: Romain and I had discussed watching general feedback on this feature from enterprise before deciding whether or not to disable for ESR68. Based on what we've been seeing over the past week (as folks have started to deploy 68), it's causing issues so we should disable for now and figure out a plan moving forward.

Comment 4

[Mike Kaply [:mkaply]]

Fixing tests for these is going to be problematic. All of the tests assume profile per channel.

Any thoughts on how best to accomplish this?

Comment 5

[Mike Kaply [:mkaply]]

Here's what the patch looked like:

bool nsToolkitProfileService::UseLegacyProfiles() {
  return StringEndsWith(
             NS_LITERAL_CSTRING(NS_STRINGIFY(MOZ_APP_VERSION_DISPLAY)),
             NS_LITERAL_CSTRING("esr")) ||
         !!PR_GetEnv("MOZ_LEGACY_PROFILES");
}

Comment 6

[Dave Townsend [:mossop]]

I'm not sure there is a good way. There are a few tests written to check that reverting to legacy profiles works, it might just mean making sure theose work on esr and disabling the rest.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Hi, are there any updates on this bug? I'd like to send the ESR smoketesting email to the Enterprise list next week and it would be good if this change was included in it if we are going to proceed with making this change.

Comment 8

[Mike Kaply [:mkaply]]

Unfortunately it's way too complicated to remove because it breaks all the tests. I'm going to add a quick windows only policy to disable it.

Comment 9

[Mike Kaply [:mkaply]]

Attachment: Bug 1574963 - Add a policy for using legacy profiles on Windows.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/18cdbda1b5e1
Add a policy for using legacy profiles on Windows. r=mossop

Comment 11

[Dorel Luca [:dluca]]

Backed out changeset 18cdbda1b5e1 (bug 1574963) for build bustage in /toolkit/profile/nsToolkitProfileService.cpp. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=269496400&repo=autoland&lineNumber=35376

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&revision=18cdbda1b5e1249e1741c7a023ca4d037b33ccf3

Backout:
https://hg.mozilla.org/integration/autoland/rev/d182eed48918874f42b48b64c5d4ca1526c04e28

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/eaa0c1e72e51
Add a policy for using legacy profiles on Windows. r=mossop

Comment 13

[Mike Kaply [:mkaply]]

Forgot to #ifdef windows code. Fixed.

Comment 14

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/eaa0c1e72e51

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Is this something you wanted to uplift for 68.2esr?

Comment 16

[Mike Kaply [:mkaply]]

Attachment: Bug 1574963 - Add description for LegacyProfiles policy.

Comment 17

[Mike Kaply [:mkaply]]

Yes, but I forgot the translation. As soon as that's approved and in, I'll request.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/009c68b4bc9b
Add description for LegacyProfiles policy. r=flod,fluent-reviewers

Comment 19

[Mike Kaply [:mkaply]]

Comment on attachment 9097818 [details]
Bug 1574963 - Add a policy for using legacy profiles on Windows.

Beta/Release Uplift Approval Request

• User impact if declined: Administrators not able to prevent creation of additional profiles (common problem).
  Putting on beta to match corresponding ESR.
• 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:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low risk. Only affects Windows policy, code path already existed.
• String changes made/needed: String involved, but l10n has already OKed English only for policy strings.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This has been a consistent problem on the enterprise mailing list (ESR creating extra profiles and breaking people).
• User impact if declined: Administrators not able to prevent creation of additional profiles (common problem).
  Putting on beta to match corresponding ESR.
• Fix Landed on Version: 71
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low risk. Only affects Windows policy, code path already existed.
• String or UUID changes made by this patch: String involved, but l10n has already OKed English only for policy strings.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9097818 [details]
Bug 1574963 - Add a policy for using legacy profiles on Windows.

Allows enterprise users to disable profile-per-install via policy. l10n changes approved by product (English-only strings not a problem). Approved for 70.0b14 and 68.2esr.

Comment 21

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/009c68b4bc9b

Comment 22

[ovidiu boca[:Ovidiu]]

Hi Mike, can you please add a scenario or some STR in order to be able to verify this fix, please let us know what is the expected behaviour in this case. Please let us know how do you want to proceed. Also, Dave, I know that you created the Dedicated feature, so I think it will be a good idea to have your opinion on this, maybe some risk areas. Thanks

Comment 23

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/releases/mozilla-beta/rev/286cdf5bc9f3
https://hg.mozilla.org/releases/mozilla-beta/rev/e62d13f0a325

Comment 24

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-esr68/rev/822fcb10f6fe
https://hg.mozilla.org/releases/mozilla-esr68/rev/2eed5fdce272

Comment 25

[Mike Kaply [:mkaply]]

Hi Mike, can you please add a scenario or some STR in order to be able to verify this fix, please let us know what is the expected behaviour in this case. Please let us know how do you want to proceed. Also, Dave, I know that you created the Dedicated feature, so I think it will be a good idea to have your opinion on this, maybe some risk areas. Thanks

This is the equivalent of setting the MOZ_LEGACY_PROFILES environment variable to turn this feature completely off.

I'll create a new ADMX file so you can test this.

Comment 26

[Mike Kaply [:mkaply]]

I've added this policy to the ADMX file here:

https://github.com/mozilla/policy-templates/tree/master/windows

To test, put two copies of the ESR in two different directories and verify they share a profile and don't create separate profiles.

Comment 27

[ovidiu boca[:Ovidiu]]

I verified this issue on Windows 10 (1903) with FF ESR 68.2(2019-10-10) and I can confirm the fix, only one profile is created. I see that the Firefox 71 and 70 flags are marked as fixed, this means that the fix should be verified also on 71 and 70?

Prerequisites that I did to be able to verify this issue on ESR:

1. Go to https://github.com/mozilla/policy-templates
2. Download the zip and from the windows folder copy the .admx in C:\Windows\PolicyDefinitions
3. From the same folder (step2) go to the en-US and copy the .adml files into C:\Windows\PolicyDefinitions\en-US
4. Give a Windows search after gpedit.msc -> the local Group Policy Editor user interface is open.
5. Go to Administrative Templates -> Mozilla -> Firefox - in the normal way it doesn't make any difference from where you access it (Local Computer Policy or User Configuration)
6. You will see the Legacy Profiles file, change enable or disable, depends on what do you want to do.

Please let me know if there is something more that needs to be done here.

Comment 28

[Mike Kaply [:mkaply]]

That was exactly right. Thanks!

Comment 30

[chrisdhuber]

I have a similiar problem on a mac. I am trying to restrict a user's web usage through the leechblock application. I can force install leechblock via policies, but all of the settings are lost when a new profile is created. Yet simply copying the firefox application file allows a user to create a new profile. Any extension of this policy to macs would be greatly appreciated.

Comment 31

[Mike Kaply [:mkaply]]

My recommendation would be that you set the environment variables at the system level on the machine:

https://support.mozilla.org/en-US/kb/understanding-depth-profile-installation

Unfortunately there's no easy way to read Mac configuration profiles at startup in our current architecture.