1524205 - Permissions mismatch between install path and registry entries leads to duplicated uninstall key

Status: NEW

(Firefox :: Installer, defect, P3)

Description

[sworddragon2]

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

Steps to reproduce:

1. On a fresh Windows 10 system (or probably also one without Firefox being installed) download the second-newest version of Firefox.
2. Install Firefox without the maintenance service.
3. Start Firefox and open the "About Firefox" menu (for example via the menu bar -> Help -> "About Firefox").
4. Allow Firefox to restart after it downloaded the update.
5. Once Firefox finished restarting check the software list of Windows.

Actual results:

An additional software list entry got created.

Expected results:

The old software list entry should have been updated.

Additional information:

If I remember correctly the initial installation of Firefox prompted for higher permissions while the update via "About Firefox" never did. In my case the old software list entry is located in "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Mozilla Firefox 64.0.2 (x64 de)" while the new software list entry is located in "Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\Mozilla Firefox 65.0 (x64 de)".

My assumption is that this is just a permission issue. Since the initial installation prompted for higher permissions but the manual update never did, the originial entry could not be overwritten and a software list entry in the users context had to been created instead. However, I'm curious why the manual update succeeded in updating Firefox's programm folder but failed in updating the software list entry.

A negative side-effect of this issue is that users being unaware of this would probably just try to uninstall the old entry which I guess would also unexpectedly remove the current Firefox installation for them.

Comment 1

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

This is managed by the installer's helper.exe which is launched after a successful update so moving over to installer.

Comment 2

[Gingerbread Man]

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #1)

This is managed by the installer's helper.exe which is launched after a successful update so moving over to installer.

You yourself filed bug 773077 about helper.exe / HKCU interaction in Toolkit :: Application Update. Bug 789743 that it was duped to is also there ¯_(ツ)_/¯

Comment 3

[Molly Howell (she/her) (mostly inactive)]

Thanks for reporting this and for looking up those registry entries. I think you're right that the problem must have been that the process that updates those registry entries (the helper.exe that Robert mentioned) somehow didn't get the permissions it needed; it won't try to use HKEY_CURRENT_USER unless it can't write to HKEY_LOCAL_MACHINE. We might want to change how that situation gets handled; a single uninstall entry with the wrong version information is probably a less bad user experience than two entries, one of which is wrong. I was working on something like that in bug 1201734, but my first attempt there was overcomplicated and it kind of got dropped.

I have two questions for you:

1. Can you check the permissions on your installation directory? I suspect this wouldn't have happened if it was something like the default Program Files permissions, but that needs to be verified.
2. Do you have the Mozilla Maintenance Service installed and enabled? You can check if its enabled in the Firefox Options, it's the checkbox called "Use a background service to install updates".

Thanks again.

(In reply to Gingerbread Man from comment #2)

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #1)

This is managed by the installer's helper.exe which is launched after a successful update so moving over to installer.

You yourself filed bug 773077 about helper.exe / HKCU interaction in Toolkit :: Application Update. Bug 789743 that it was duped to is also there ¯_(ツ)_/¯

This one might go either way depending on how it's diagnosed and what the proper fix ends up being; I'll move it back to Update if that turns out to be appropriate.

Comment 4

[sworddragon2]

(In reply to Matt Howell (he/him) [:mhowell] from comment #3)

1. Can you check the permissions on your installation directory? I suspect this wouldn't have happened if it was something like the default Program Files permissions, but that needs to be verified.

Since Firefox succeeded updating its programm folder with my user permissions all seems to be correct here (but the issue of getting 2 software list entries still happened). Firefox's installation target was altered by changing C: to D: (so the installation path is "D:\Program Files\Mozilla Firefox". The permissions for DESKTOP-\User are Execute,List,Modify while for the same DESKTOP-\Admin they are All,Modify,Execute,List,Read,Write. If those are the wrong users you are looking for, the other 2 are being Authenticated User with Modify,Execute,List,Read,Write and SYSTEM with All,Modify,Execute,List,Read,Write.

(In reply to Matt Howell (he/him) [:mhowell] from comment #3)

2. Do you have the Mozilla Maintenance Service installed and enabled? You can check if its enabled in the Firefox Options, it's the checkbox called "Use a background service to install updates".

As mentioned in the startpost the maintenance service was not being installed and thus the checkbox in the settings doesn't even exist.

(In reply to Matt Howell (he/him) [:mhowell] from comment #3)
We might want to change how that situation gets handled; a single uninstall entry with the wrong version information is probably a less bad user experience than two entries, one of which is wrong.

Either case is just not good. I also think this issue is actually very simple: According to https://support.mozilla.org/en-US/kb/what-mozilla-maintenance-service the maintenance service exists to avoid the need to prompt for higher permissions. So once the updater notices it has not sufficient permissions it should just prompt for them.

Comment 5

[Molly Howell (she/her) (mostly inactive)]

Thanks for the info. I think the Authenticated Users write permission is the anomaly here, and it's indirectly causing the issue; the default Program Files directory doesn't have that. Without the Maintenance Service enabled, the updater will check whether it has write permissions on the installation directory to determine whether it needs to prompt for elevation. It doesn't check the permissions on the registry entries, because the check happens in cross-platform code that doesn't know about the registry, so it doesn't try to elevate and doesn't realize that later on it won't be able to update the entries that were created originally by the installer (which did run elevated). Having the Maintenance Service installed and enabled should prevent this because it would always be used regardless of the permissions and the whole update process would run at SYSTEM privileges.

One fix would indeed be to have helper.exe prompt for elevation if it finds that it needs to update keys it doesn't have permissions on. Right now it doesn't have any way to detect that because the permissions mismatch here between the registry and the install path is not an anticipated situation (it's also a very uncommon situation, so I can't put a very high priority on fixing this I'm afraid). I need to think through any implications there might be in making that code suddenly able to show UI, since it's always run silently.

Comment 6

[sworddragon2]

Thanks for the details why the issue happens exactly. I see 3 potential ways how this could be solved:

[1] The maintenance service will be made mandatory.
[2] Since the installer runs with higher permissions it could align the permissions of the programm folder if it notices they can make issues (like choosing D: instead of C:).
[3] The use of a platform-specific feature gets a platform-specific safety-check (checking the permissions on the registry entry).

While the first solution might be the most simple one some people will just dislike the change and probably beging to disable the service via Windows's services.msc (as they do since over a decade with driver helpers and other stuff) resulting in the same issue we currently have.

The second solution would fix the issue if a non-default installation directory is being choosed which would fix the issue for me and some others. However, once an user achieves somehow to get a permission mismatch via a specific setup he will just end up on the same issue again.

The third solution seems to be the most obvious to me. While the behavior of not selecting the maintenance service and choosing a non-default installation path might be uncommon it is still a valid choice. Also I'm a bit curious:
(In reply to Matt Howell (he/him) [:mhowell] from comment #5)

I need to think through any implications there might be in making that code suddenly able to show UI, since it's always run silently.

Wasn't there always already the possibility that the UAC dialog could show up? Like if even the programm folder did not have sufficient permissions to update it.

Comment 7

[Molly Howell (she/her) (mostly inactive)]

Thanks for the suggestions. Unfortunately none of them are going to work out, and I'll explain why.

(In reply to sworddragon2 from comment #6)

[1] The maintenance service will be made mandatory.

We can't do this because we want to support running the installer as a user who doesn't have permissions to install services, so we have to be able to run updates without the service.

[2] Since the installer runs with higher permissions it could align the permissions of the programm folder if it notices they can make issues (like choosing D: instead of C:).

We've considered something related to this before, but it turns out to be too difficult (probably not possible in general) to figure out the system administrator's intent behind choosing a particular path or set of permissions for that path; we would get it wrong sometimes, and when we do it would be difficult for a user to diagnose the problem or figure out how to get around it.

[3] The use of a platform-specific feature gets a platform-specific safety-check (checking the permissions on the registry entry).

We could do this, but the responsibility for these two things (the program files and the registry entries) is in two different parts of the code which are very distant from one another, so making them need to know what the other is doing like this would become a potential source of bugs when either one is changed and they need to be kept in sync. Structures like that are usually best avoided.

(In reply to Matt Howell (he/him) [:mhowell] from comment #5)

I need to think through any implications there might be in making that code suddenly able to show UI, since it's always run silently.

Wasn't there always already the possibility that the UAC dialog could show up? Like if even the programm folder did not have sufficient permissions to update it.

It's a subtle difference, but the prompts you're thinking of come from earlier on in the update process and would appear immediately after the browser is restarted. This one would happen after the program files have been updated, so at least a few seconds later, and I'm worried about what user perception of that would be; at best, it might look like updates are running slowly, at worst it might be a long enough delay to make users unsure if it's actually associated with the Firefox update. I think this might be the best solution anyway though, because it's the only one that really solves the problem and it's a pretty uncommon configuration that would even see the effect.

Comment 8

[sworddragon2]

(In reply to Matt Howell (he/him) [:mhowell] from comment #7)

We could do this, but the responsibility for these two things (the program files and the registry entries) is in two different parts of the code which are very distant from one another, so making them need to know what the other is doing like this would become a potential source of bugs when either one is changed and they need to be kept in sync. Structures like that are usually best avoided.

Eventually this could be solved by a more or less slight refactoring of the affected parts. But I see why this issue might be not a high priority.

(In reply to Matt Howell (he/him) [:mhowell] from comment #7)

It's a subtle difference, but the prompts you're thinking of come from earlier on in the update process and would appear immediately after the browser is restarted. This one would happen after the program files have been updated, so at least a few seconds later, and I'm worried about what user perception of that would be; at best, it might look like updates are running slowly, at worst it might be a long enough delay to make users unsure if it's actually associated with the Firefox update. I think this might be the best solution anyway though, because it's the only one that really solves the problem and it's a pretty uncommon configuration that would even see the effect.

I see, for example a slow HDD could cause a significant delay until the programm folder is updated and a prompt for the registry might appear then. I wonder if it could be an option to swap these steps (updating the registry first) to heavily reduce the average delay until prompting for higher permissions might pop up (for the probably more uncommon case where the registry has enough permissions but the programm folder does not) or if this would cause specific issues or require a more advanced refactoring.

Comment 10

[sworddragon2]

Hi again,

did by any chance something improve within those 6 years that might make a solution more accessible? Or did this one kind of got implemented?:

(In reply to sworddragon2 from comment #6)

[2] Since the installer runs with higher permissions it could align the permissions of the programm folder if it notices they can make issues (like choosing D: instead of C:).

I'm asking the latter because I don't precisely remember anymore what I did 6 years ago to workaround this issue, probably I removed the Authenticated Users permission from "D:\Program Files" (as it currently does not exist there as well) and possibly I applied this change recursively. However, when I make a look at the permissions now for "D:\Program Files\Mozilla Firefox" I see Authenticated Users in there but it lacks write permissions.

A bit offtopic: I was remembered yesterday on this issue (and did those checks now) because I read somewhere that LibreOffice forked code from the Mozilla Maintenance service to implement an update function (as it was limited to only being able to check for updates but not to apply them the last time I checked) and I guess dependent on what they all forked it might or might not be affected by this bug as well.