Open Bug 1840617 Opened 11 months ago Updated 10 months ago

Updater fails to escalate privileges as needed if the install directory permissions grant the user full control but are not inheritable

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: stecoop001-mozilla, Unassigned)

References

Details

(Whiteboard: [fidedi-ope])

Attachments

(9 files)

last-update.log
1.91 KB, application/octet-stream
Details
ScreenCapture - 2023-07-07.jpg
150.60 KB, image/jpeg
Details
updater.exe
398.00 KB, application/x-msdownload
Details
BrowserConsole-1.txt
1.89 KB, text/plain
Details
BrowserConsole-2.txt
5.47 KB, text/plain
Details
backup-update.log
1.91 KB, application/octet-stream
Details
extra-logging.log
2.17 KB, application/octet-stream
Details
last-update.log
1.91 KB, application/octet-stream
Details
Clipboard-1.jpg
102.38 KB, image/jpeg
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

I'm using Firefox 115.0b9; I'm trying to update to version 115.0. In the Help/About screen, I click on "Update to 115.0".

Actual results:

It appears to download PART of something about 6.7 mb in size but only gets to around 1.5 mb. Then the "Restart to Update" button appears; I click on it; Firefox closes for a few seconds, and reopens. I go to Help/About and the "Restart to Update" button is still there and the current version number is still 115.0b9.

Expected results:

It should have updated to 115.0.

BTW, the Firefox Installer installs the 114.??? version or the 115.0b9 version, seemly at random. I've tried several times with it.

And I can't find a full blown installable download for version 115.0...it will only give me the one for 114.0.

The Bugbug bot thinks this bug should belong to the 'Toolkit::Application Update' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Application Update
Product: Firefox → Toolkit
Version: other → unspecified

I tried disabling Mozilla VPN during the update process; same results, no change.

Hello, thanks for filing a bug.

I currently cannot reproduce any of the issues that you describe. I downloaded the Firefox Beta installer and it definitely seems to contain only 115.0b9. And when I install and run it, I successfully update to 115.0.

(In reply to Steven Cooper from comment #1)

BTW, the Firefox Installer installs the 114.??? version or the 115.0b9 version, seemly at random. I've tried several times with it.

You are getting different versions installed from the exact same installer? Or you are downloading it multiple times and getting different installers? In the former case, can you please attach the installer that is doing that to this bug? In the latter case, can you please give us the download URL that has this behavior?

And I can't find a full blown installable download for version 115.0

Yes, that is because we don't distribute this installer yet because it's a Release Candidate.

Before we ship a new version to the Release Firefox channel, we first ship it to the Beta channel. This is different from what we normally ship to the Beta channel, because those are built for the Beta channel not the Release channel. To prevent Beta users from being switched to the Release channel when they install a Release Candidate, the updater doesn't update the file that determines what update channel the user is on.

We do not distribute installers for Release Candidates, because there is no logical audience to distribute them to. If we distributed them to the Beta channel audience, they would end up on the Release channel. If we distributed them to the Release channel audience, they would be getting code that isn't tested up to the level that they would expect of the Release channel.

it will only give me the one for 114.0.

Well sure, but that will be a Release channel installer, not a Beta channel installer like 115.0b9 would be. Are you looking for a Release installer or a Beta installer?

(In reply to Steven Cooper from comment #0)

It appears to download PART of something about 6.7 mb in size but only gets to around 1.5 mb. Then the "Restart to Update" button appears; I click on it; Firefox closes for a few seconds, and reopens. I go to Help/About and the "Restart to Update" button is still there and the current version number is still 115.0b9.

Can you reproduce this problem? That is to say, does it happen again if you do it again? If so, can you please collect some logs and attach them to this bug?

  1. Navigate to about:config.
  2. Set app.update.log to true.
  3. Open the Browser Console either with the hotkey Control+Shift+J (Command+Shift+J on macOS), or via Hamburger Menu->More Tools->Browser Console
  4. In the Filter textbox at the top, enter AUS: to filter out everything except the update messages.
  5. Navigate to the "Update" section of about:preferences. It should automatically check for an update.
  6. Once the update check has completed, copy the messages out of the Browser Console and attach them to this bug.
  7. Click the "Restart to Update" button
  8. After Firefox restarts, navigate to about:support
  9. Find the "Update Folder" entry and click "Open Folder".
  10. Open the updates directory.
  11. Inside, you should find files named last-update.log and backup-update.log. Attach both of these files to this bug.
Flags: needinfo?(stecoop001-mozilla)

(In reply to Robin Steuber (they/them) [:bytesized] from comment #4)

Hello, thanks for filing a bug.

I currently cannot reproduce any of the issues that you describe. I downloaded the Firefox Beta installer and it definitely seems to contain only 115.0b9. And when I install and run it, I successfully update to 115.0.

(In reply to Steven Cooper from comment #1)

BTW, the Firefox Installer installs the 114.??? version or the 115.0b9 version, seemly at random. I've tried several times with it.

You are getting different versions installed from the exact same installer? Or you are downloading it multiple times and getting different installers? In the former case, can you please attach the installer that is doing that to this bug? In the latter case, can you please give us the download URL that has this behavior?

I downloaded it three or four times, but there was no indication which version the installer was for. I don't know what the URL was that I downloaded from other than it was Mozilla's.

And I can't find a full blown installable download for version 115.0

Yes, that is because we don't distribute this installer yet because it's a Release Candidate.

Before we ship a new version to the Release Firefox channel, we first ship it to the Beta channel. This is different from what we normally ship to the Beta channel, because those are built for the Beta channel not the Release channel. To prevent Beta users from being switched to the Release channel when they install a Release Candidate, the updater doesn't update the file that determines what update channel the user is on.

We do not distribute installers for Release Candidates, because there is no logical audience to distribute them to. If we distributed them to the Beta channel audience, they would end up on the Release channel. If we distributed them to the Release channel audience, they would be getting code that isn't tested up to the level that they would expect of the Release channel.

it will only give me the one for 114.0.

Well sure, but that will be a Release channel installer, not a Beta channel installer like 115.0b9 would be. Are you looking for a Release installer or a Beta installer?

I want to get away from the Beta version and get the release version WITHOUT losing my bookmarks, saved logins and passwords, cookies, etc.
When I tried to reinstall version 114, it wouldn't let use the old profile and forced me to create a new profile, losing all the old bookmarks and stuff. Firefox has a trap in it that prevents the user from using an older version with a profile from a newer version. NO OPTIONS!!!

I reinstalled version 115.0b9 and was able to reclaim my old profile and save what was lost.

(In reply to Steven Cooper from comment #0)

It appears to download PART of something about 6.7 mb in size but only gets to around 1.5 mb. Then the "Restart to Update" button appears; I click on it; Firefox closes for a few seconds, and reopens. I go to Help/About and the "Restart to Update" button is still there and the current version number is still 115.0b9.

Can you reproduce this problem? That is to say, does it happen again if you do it again? If so, can you please collect some logs and attach them to this bug?

It happens evertime I try to update through the About/Help menu.

  1. Navigate to about:config.
  2. Set app.update.log to true.
  3. Open the Browser Console either with the hotkey Control+Shift+J (Command+Shift+J on macOS), or via Hamburger Menu->More Tools->Browser Console
  4. In the Filter textbox at the top, enter AUS: to filter out everything except the update messages.
  5. Navigate to the "Update" section of about:preferences. It should automatically check for an update.
  6. Once the update check has completed, copy the messages out of the Browser Console and attach them to this bug.
  7. Click the "Restart to Update" button
  8. After Firefox restarts, navigate to about:support
  9. Find the "Update Folder" entry and click "Open Folder".
  10. Open the updates directory.
  11. Inside, you should find files named last-update.log and backup-update.log. Attach both of these files to this bug.

I don't have time right now to go through all that; I'll try to go through it this weekend and see what comes up.

In the meantime, I seem to be stuck with version 115.0b9.

Flags: needinfo?(stecoop001-mozilla)

(In reply to Steven Cooper from comment #5)

I want to get away from the Beta version and get the release version WITHOUT losing my bookmarks, saved logins and passwords, cookies, etc.
When I tried to reinstall version 114, it wouldn't let use the old profile and forced me to create a new profile, losing all the old bookmarks and stuff. Firefox has a trap in it that prevents the user from using an older version with a profile from a newer version. NO OPTIONS!!!

Yes, that is intentional. Not every Firefox version uses the exact same data format for every component of the profile. Generally, Firefox knows how to identify and upgrade older profile data, but older versions of Firefox have no way of knowing how to identify and downgrade newer data. It is possible to force it to use the profile anyways, but this can result in problems including data loss so it isn't recommended.

The recommended way of doing something like this is to use Firefox Sync, which will synchronize many of these things across profiles of potentially different versions. But it doesn't synchronize everything and I'm not sure off the top of my head which of the things you want to retain would be synchronized and which wouldn't.

I don't have time right now to go through all that; I'll try to go through it this weekend and see what comes up.

Alright. I don't think there is anything I can do with the information you have provided so far, so this bug will be on hold until you can provide more.

Attached file last-update.log —

Okay, I've followed the steps you outlined; however two things did not happen as forecast:

At step 7, there was an "Update To 115" button, not a "Restart To Update" button. I clicked on that, Firefox downloaded a 6.7 mB file (in It's entirety this time); then the "Restart To Update" button appeared; I clicked on it, Firefox closed for a few seconds, then reopened; I followed the remaining steps.

There was no 'backup-update.log', only the 'last-update.log', which I've attached.
Here are the console messages:

AUS:AUM AppUpdater:check - currentState=STATE_IDLE
AUS:AUM AppUpdater:check - starting update check
AUS:SVC CheckerService:checkForUpdates - checkType: 2
AUS:SVC CheckerService:checkForUpdates - Making new check request for check id 2.
AUS:SVC CheckerService:getUpdateURL - checkType: 2
AUS:SVC CheckerService:getUpdateURL - update URL: https://aus5.mozilla.org/update/6/Firefox/115.0/20230622161221/WINNT_x86_64-msvc-x64/en-US/beta/Windows_NT%2010.0.0.0.19045.3086%20(x64)/ISET:SSE4_2,MEM:16252/default/default/update.xml?force=1
AUS:SVC CheckerService:#updateCheck - sending request to: https://aus5.mozilla.org/update/6/Firefox/115.0/20230622161221/WINNT_x86_64-msvc-x64/en-US/beta/Windows_NT%2010.0.0.0.19045.3086%20(x64)/ISET:SSE4_2,MEM:16252/default/default/update.xml?force=1
AUS:SVC CheckerService:#updateCheck - request got 'load' event
AUS:SVC CheckerService:#updateCheck - request completed downloading document
AUS:SVC CheckerService:#updateCheck - number of updates available: 1
AUS:AUM AppUpdater:check - Update check succeeded
AUS:SVC UpdateManager:_loadXMLFileIntoArray - XML file does not exist. path: C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38\updates\E7CF176E110C211B\active-update.xml
AUS:SVC UpdateManager:UpdateManager - Initialized downloadingUpdate to null
AUS:SVC UpdateManager:UpdateManager - Initialized readyUpdate to null
AUS:SVC getCanApplyUpdates - testing write access C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38\updates\E7CF176E110C211B\update.test
AUS:SVC isServiceInstalled - returning true
AUS:SVC shouldUseService - returning false
AUS:SVC getCanApplyUpdates - able to apply updates
AUS:AUM AppUpdater:check - Need to wait for user approval to start the download.

BTW: I'm still stuck on version 115.0b9

(In reply to Steven Cooper from comment #8)

At step 7, there was an "Update To 115" button, not a "Restart To Update" button.

Ah, yes. You must have the "Check for updates but let you choose to install them" option selected. That is expected in that case.

Here are the console messages:

This seems to be an incomplete log. It stops at

AUS:AUM AppUpdater:check - Need to wait for user approval to start the download.

Which it shouldn't since you clicked the "Update To 115" button. I'm guessing that you collected it before the "Restart To Update" button came up? But I think that I actually got what I need so no need to collect another one, I don't think.

When you restarted to install this update, did it show a UAC (User Account Control) prompt asking if the Firefox Software Updater could use elevated privileges? Did you accept it? Alternately, have you disabled User Account Control for your current user account?

Flags: needinfo?(stecoop001-mozilla)

(In reply to Robin Steuber (they/them) [:bytesized] from comment #9)

(In reply to Steven Cooper from comment #8)

At step 7, there was an "Update To 115" button, not a "Restart To Update" button.

Ah, yes. You must have the "Check for updates but let you choose to install them" option selected. That is expected in that case.

Here are the console messages:

This seems to be an incomplete log. It stops at

AUS:AUM AppUpdater:check - Need to wait for user approval to start the download.

Which it shouldn't since you clicked the "Update To 115" button. I'm guessing that you collected it before the "Restart To Update" button came up? But I think that I actually got what I need so no need to collect another one, I don't think.

The order of the steps you had me follow was to collected the messages in the browser console BEFORE clicking the "Restart to Update".

When you restarted to install this update, did it show a UAC (User Account Control) prompt asking if the Firefox Software Updater could use elevated privileges? Did you accept it? Alternately, have you disabled User Account Control for your current user account?

When Firefox restarted, there were no prompts of any kind. Firefox closed and, after a few seconds, reopened.

It should be noted that I only encountered this problem after switching to the Beta version of Firefox after reporting a bug in the Bookmarks Menu (Bug 1838567); it happened when updating from 115.0b7 to 115.0b8, and from 115.0b8 to 115.0b9, as well the recent beta update attempts. If I were to hazard a guess, I would say the problem is in the updater for the Beta channel; I have never run into this in the Release versions.
(I'm assuming you have a different updater for the Beta versions than for the Release versions.)

I would also mention that I have successfully updated to the Release version of 115.0 by downloading the full version from this URL:

https://www.mozilla.org/en-US/firefox/all/#product-desktop-release

Also, the Beta versions I could only update by downloading the full versions from this URL:

https://www.mozilla.org/en-US/firefox/all/#product-desktop-beta

When a new RELEASE version comes out, I will let you know if the problem recurs.

Flags: needinfo?(stecoop001-mozilla)

I just tried to update to the release version 115.0.1; Firefox downloaded a 6.2 mb file then displayed the "Restart To Update" button; I clicked on it,
Firefox closed, after a few seconds Firefox reopened. I went to the Help menu and the "Restart To Update" button is still there.

Any idea how I can make a screen capture video to show you what is happening?

(In reply to Steven Cooper from comment #11)

I just tried to update to the release version 115.0.1; Firefox downloaded a 6.2 mb file then displayed the "Restart To Update" button; I clicked on it,
Firefox closed, after a few seconds Firefox reopened. I went to the Help menu and the "Restart To Update" button is still there.

Any idea how I can make a screen capture video to show you what is happening?

A screen capture will not help me figure out why this is happening.

I feel like I should mention since you seem concerned about the file size that this isn't actually a problem. To update from 115 to 115.0.1, Firefox ought to download this update file, which is 6.2 MB in size.

When you start Firefox again, do you still see the "Restart to Update" button or has it gone away? Is Firefox still attempting to update?

Could you please follow these steps and let me know what you find?

  1. Hit the Windows button in the taskbar
  2. Type User Account Control
  3. Click on "Change User Account Control Settings"
  4. Tell me what this window shows. What position is the slider at? What does the text to the right of it say?
Flags: needinfo?(stecoop001-mozilla)
Flags: needinfo?(stecoop001-mozilla)

(In reply to Robin Steuber (they/them) [:bytesized] from comment #12)

(In reply to Steven Cooper from comment #11)

I just tried to update to the release version 115.0.1; Firefox downloaded a 6.2 mb file then displayed the "Restart To Update" button; I clicked on it,
Firefox closed, after a few seconds Firefox reopened. I went to the Help menu and the "Restart To Update" button is still there.

Any idea how I can make a screen capture video to show you what is happening?

A screen capture will not help me figure out why this is happening.

I feel like I should mention since you seem concerned about the file size that this isn't actually a problem. To update from 115 to 115.0.1, Firefox ought to download this update file, which is 6.2 MB in size.

I'm not concerned so much about the size of the file as much as I am that sometimes it appears that the entire file does not get downloaded.
The "Download Counter" sometimes doesn't make it all the way to the stated size of the file, but maybe it sometimes doesn't keep up.

When you start Firefox again, do you still see the "Restart to Update" button or has it gone away? Is Firefox still attempting to update?

Yes, however, I have reinstalled 115.0 and now it wants me to update to 115.0.1. (I'm saving the install files until this issue is resolved.)

Could you please follow these steps and let me know what you find?

  1. Hit the Windows button in the taskbar
  2. Type User Account Control
  3. Click on "Change User Account Control Settings"
  4. Tell me what this window shows. What position is the slider at? What does the text to the right of it say?

Eezy-peezy...see attached screen dump.

(In reply to Steven Cooper from comment #14)

Yes, however, I have reinstalled 115.0 and now it wants me to update to 115.0.1. (I'm saving the install files until this issue is resolved.)

I'm a little confused. If you didn't update successfully, why did you need to reinstall in order to be at 115.0? What version were you at prior to reinstalling?

Flags: needinfo?(stecoop001-mozilla)

(In reply to Robin Steuber (they/them) [:bytesized] from comment #15)

(In reply to Steven Cooper from comment #14)

Yes, however, I have reinstalled 115.0 and now it wants me to update to 115.0.1. (I'm saving the install files until this issue is resolved.)

I'm a little confused. If you didn't update successfully, why did you need to reinstall in order to be at 115.0? What version were you at prior to reinstalling?

To see if the "Restart To Update" would go away; it did, but of course was replaced with "Update To 115.0.1".

I have downloaded the install file for 115.0.1, but have not installed it yet, while we try to find the cause of the restart not working.
Obviously, I have the option to do all manual updates from now on, but, there's a bug in the auto update...I want it squashed.

BTW, I just realized, when the updates were successful, Windows would ask if I want to allow Firefox to make changes to my system.
Since this update problem has begun, I've not seen that; either Windows is blocking the update process without asking me, or the updater is not executing.

Flags: needinfo?(stecoop001-mozilla)

(In reply to Steven Cooper from comment #16)

BTW, I just realized, when the updates were successful, Windows would ask if I want to allow Firefox to make changes to my system.
Since this update problem has begun, I've not seen that; either Windows is blocking the update process without asking me, or the updater is not executing.

Oh. That is a very bad sign. Usually I wait to fully diagnose a problem to give it a severity, but I think that a failure to show the escalation dialog is almost certainly an S2, at least. So I am going to set S2 severity for now.

I am going to try to see if I can make a few changes to my configuration and see if I can reproduce the problem on my machine. If not, I will be back with more debugging questions shortly.

Severity: -- → S2
Summary: Restart not working → Updater not escalating privileges via UAC when it ought to

(In reply to Robin Steuber (they/them) [:bytesized] from comment #17)

(In reply to Steven Cooper from comment #16)

BTW, I just realized, when the updates were successful, Windows would ask if I want to allow Firefox to make changes to my system.
Since this update problem has begun, I've not seen that; either Windows is blocking the update process without asking me, or the updater is not executing.

Oh. That is a very bad sign. Usually I wait to fully diagnose a problem to give it a severity, but I think that a failure to show the escalation dialog is almost certainly an S2, at least. So I am going to set S2 severity for now.

I am going to try to see if I can make a few changes to my configuration and see if I can reproduce the problem on my machine. If not, I will be back with more debugging questions shortly.

If there is a problem with my system, that Firefox is not handling well, I would certainly like to know, so I can fix my system.

Note, I also use Thunderbird; it updated this evening without any problems, just in case that's helpful.

Reminder, it all worked fine before I installed BETA 115.0b7; perhaps that version corrupted something in Firefox's or Windows configuration.

Just a quick update - I'm working on making more time to spend on this bug. Unfortunately, I think we are at the point where I've gotten as much information as there is to get from existing logs. Which means that I'll likely have to make a custom build that adds substantially more logging around this specific issue. This can be a bit time consuming, but I'll try to be sure to get to it before the end of the week.

Oh, just as I sent this, I realized that this may actually be even a bit more complicated than that because in order for the custom build to be useful, update has to be functional. Usually custom builds don't really have anything to update to since they aren't on a standard update channel. Our team has its own update channel (Oak) that we can use when we need to make unusual builds that are capable of updating, so I'll probably have to use that. That can be a bit complicated, but I'll get on it ASAP.

Whiteboard: [fidedi-ope]

Apologies, I was really hoping to have the custom build done by the end of the week, but it's the end of the day and it's not quite ready. I should have it ready on Monday.

Gah, I'm sorry that this continues to take so long. I've got a custom build ready, but there seems to be a problem with the digital signature on it, and consequently it won't install any updates. Which is obviously important for testing this bug. Hopefully I can get this resolved quickly.

Depends on: 1844422
Attached file updater.exe —

Alright, sorry that took so long. I've finally got an updater binary that produces extra logging around the issue you are experiencing.

However, I believe that the usage will vary slightly depending on exactly what version you are on. I think that you are on the Release channel now, using version 115.0. Is that still correct?

A few notes, for the record:

  • This binary was built on the birch test branch and retrieved from this job by running the target.installer.exe artifact and retrieving the installed updater.exe.
  • Updater binaries reject updates that are older than the version baked into the binary. This binary instead compares against version "110.0a1" in order to ensure that it can be dropped into slightly older builds of Firefox and still update properly.
  • This binary was modified from how a typical birch branch updater binary would be built in order to use production certificates for MAR verification so that it would successfully verify Beta and Release updates.
  • This binary is not signed. I determined that signing would not be necessary for this because the signing on the updater is typically verified by the Maintenance Service and the logs in Comment 8 say: AUS:SVC shouldUseService - returning false, so the Maintenance Service is not being used.
Flags: needinfo?(stecoop001-mozilla)

(In reply to Robin Steuber (they/them) [:bytesized] from comment #24)

Created attachment 9344968 [details]
updater.exe

Alright, sorry that took so long. I've finally got an updater binary that produces extra logging around the issue you are experiencing.

However, I believe that the usage will vary slightly depending on exactly what version you are on. I think that you are on the Release channel now, using version 115.0. Is that still correct?

I have updated, manually, to 115.0.2; however, I have saved the full install files for 115.0.0, 115.0.1, & 115.0.2, so I can go back to a previous version if needed. I have also backed up my profile folder for 115.0.0 so I don't lose anything if I should have to go backwards.

A few notes, for the record:

  • This binary was built on the birch test branch and retrieved from this job by running the target.installer.exe artifact and retrieving the installed updater.exe.
  • Updater binaries reject updates that are older than the version baked into the binary. This binary instead compares against version "110.0a1" in order to ensure that it can be dropped into slightly older builds of Firefox and still update properly.
  • This binary was modified from how a typical birch branch updater binary would be built in order to use production certificates for MAR verification so that it would successfully verify Beta and Release updates.
  • This binary is not signed. I determined that signing would not be necessary for this because the signing on the updater is typically verified by the Maintenance Service and the logs in Comment 8 say: AUS:SVC shouldUseService - returning false, so the Maintenance Service is not being used.

That is all way over my head, so I'll take your word for it. 8-))

Flags: needinfo?(stecoop001-mozilla)

(In reply to Steven Cooper from comment #25)

I have updated, manually, to 115.0.2; however, I have saved the full install files for 115.0.0, 115.0.1, & 115.0.2, so I can go back to a previous version if needed. I have also backed up my profile folder for 115.0.0 so I don't lose anything if I should have to go backwards.

Alright, let's go back to 115.0. When you say you have the install files, you have a complete installer, right? We also distribute very small stub installers that find and download the most recent version. Obviously an old one of those will not help. Just in case you need it, here's the link to the 115.0 installer.

Unfortunately this is going to be a little bit complicated. The background here is that we have two different kinds of updates: partial updates and complete updates. A complete update is similar to a complete installer - it contains the whole application. A partial update is more like a patch - it is much smaller and basically contains instructions for how to change the old installation into the new one. Firefox defaults to using the partial update because it is smaller, but it doesn't work if the installation has been changed in any way because then the instructions don't make sense. But we also aren't actually expecting the update to succeed. Which is to say that there is an element of how this goes that I am unfortunately a little unsure of, but I'll do my best to give clear directions.

  1. Install 115.0 and either revert your profile to one that works with 115.0, or create a new one (Firefox will automatically prompt you to do this if you launch 115.0 when the default profile was last used by 115.0.2).
  2. Download the updater.exe binary that I attached and use it to overwrite the binary in your installation directory. If you aren't sure where your installation directory is, you can navigate to about:support and use the "Application Binary" row to find out. You may want to back up your old updater binary so you can restore it later, but if you are planning to overwrite the whole installation with 115.0.2 afterwards, the backup step isn't necessary.
  3. Open Firefox and navigate to about:config. Ensure that app.update.log is true.
  4. Open the Browser Console either with the hotkey Control+Shift+J, or via Hamburger Menu->More Tools->Browser Console.
  5. In the Filter textbox at the top, enter AUS: to filter out everything except the update messages.
  6. Navigate to the "Update" section of about:preferences. It should automatically check for an update.
  7. Wait the update check has completed and the "Ready to Update" button is shown, but don't click it yet.
  8. Copy the messages out of the Browser Console. You can either just attach them to this bug, or you can save them somewhere and attach everything all at once at the end.
  9. Click the "Restart to Update" button.
  10. After Firefox restarts, navigate once again to the "Update" section of about:preferences and click "Show Update History".
  11. Examine the most recent entry in the history (the top one). If the "Installed on" time matches the time of when we just ran the update and the "Status" does not say "Install Pending", then we have what we need and can move on. If the time does not match or the "Status" does say "Install Pending", the updater noticed that the partial update wouldn't work. In this case, make sure to tell me that this is what happened. Then repeat steps 7-10. This time you should see the failure in the update history. Oh, I don't really need both Browser Console logs, I just need the one that is collected right before the update failure.
  12. Navigate to about:support, find the "Update Folder" entry and click "Open Folder".
  13. Open the updates directory.
  14. Inside, you should find last-update.log, possibly backup-update.log, and extra-logging.log. Attach all of these files to this bug.
  15. If you backed up an installer binary, restore it now.

Sorry that that's kinda complicated, feel free to ask if you have questions. Thank you very much for helping us figure out what's going on here!

Flags: needinfo?(stecoop001-mozilla)

(In reply to Robin Steuber (they/them) [:bytesized] from comment #26)

(In reply to Steven Cooper from comment #25)

I have updated, manually, to 115.0.2; however, I have saved the full install files for 115.0.0, 115.0.1, & 115.0.2, so I can go back to a previous version if needed. I have also backed up my profile folder for 115.0.0 so I don't lose anything if I should have to go backwards.

Alright, let's go back to 115.0. When you say you have the install files, you have a complete installer, right? We also distribute very small stub

Yes, the full 55mb+ .exe files.

This is very long and complicated; I have downloaded the updater.exe file and placed it in a protected area for now; I don't have time tonight to go through this, but I will make time tomorrow. Hopefully we'll find the problem.

BTW, the original bug that started all this (Bug 1838567) has returned.

Flags: needinfo?(stecoop001-mozilla)
Attached file BrowserConsole-1.txt —
Attached file BrowserConsole-2.txt —
Attached file backup-update.log —
Attached file extra-logging.log —
Attached file last-update.log —
Attached image Clipboard-1.jpg —

I'm going to insert comments in your original instructions, becuase this did not go as planned:

(In reply to Robin Steuber (they/them) [:bytesized] from comment #26)

  1. Install 115.0 and either revert your profile to one that works with 115.0, or create a new one (Firefox will automatically prompt you to do this if you launch 115.0 when the default profile was last used by 115.0.2).

Actually, it didn't; it accepted the Profile I'd been using with 115.0.2 - perhaps becuase it's a minor version change instead of a major revision.
And it wouldn't give me the option to use the 115.0.0 profile, even though it was there in the Profiles folder with a different name.

  1. Download the updater.exe binary that I attached and use it to overwrite the binary in your installation directory. If you aren't sure where your installation directory is, you can navigate to about:support and use the "Application Binary" row to find out. You may want to back up your old updater binary so you can restore it later, but if you are planning to overwrite the whole installation with 115.0.2 afterwards, the backup step isn't necessary.
  2. Open Firefox and navigate to about:config. Ensure that app.update.log is true.
  3. Open the Browser Console either with the hotkey Control+Shift+J, or via Hamburger Menu->More Tools->Browser Console.
  4. In the Filter textbox at the top, enter AUS: to filter out everything except the update messages.

All good to this point.

  1. Navigate to the "Update" section of about:preferences. It should automatically check for an update.
  2. Wait the update check has completed and the "Ready to Update" button is shown, but don't click it yet.

There was never a "Ready to Update" button; there was a "Update to 115.0.2" button instead.

  1. Copy the messages out of the Browser Console. You can either just attach them to this bug, or you can save them somewhere and attach everything all at once at the end.

Done, in the first listing.

  1. Click the "Restart to Update" button.

Again, only shows "Update to 115.0.2"; I clicked on it, waited while it downloaded a 6.5mb file; then the "Restart to Update Firefox" button appeared. I clicked on it and Firefox closed, then restarted.

  1. After Firefox restarts, navigate once again to the "Update" section of about:preferences and click "Show Update History".
  2. Examine the most recent entry in the history (the top one). If the "Installed on" time matches the time of when we just ran the update and the "Status" does not say "Install Pending", then we have what we need and can move on. If the time does not match or the "Status" does say "Install Pending", the updater noticed that the partial update wouldn't work. In this case, make sure to tell me that this is what happened. Then repeat steps 7-10. This time you should see the failure in the update history. Oh, I don't really need both Browser Console logs, I just need the one that is collected right before the update failure.

As you can see from the screen dump, there's been no update history since updating to 114.0.1 on June 9.
I repeated steps 7 thru 10, except that there was only the "Restart to Update Firefox" button. I captured a second copy of the browser console logs, just in case.

  1. Navigate to about:support, find the "Update Folder" entry and click "Open Folder".
  2. Open the updates directory.
  3. Inside, you should find last-update.log, possibly backup-update.log, and extra-logging.log. Attach all of these files to this bug.
  4. If you backed up an installer binary, restore it now.

I hope this helps. I'm going to restore back to the 115.0.2.

How strange. It seems like even though Firefox's write check to the installation fails with Access Denied and the updater's attempt to open the Firefox binary also fails with Access Denied, the updater's attempt to open the lock file succeeds. I can't quite imagine why that would be.

Could you open the command prompt for me and send me the result of a couple of commands, please?

You can open the command prompt by pressing Win+R, typing cmd and hitting "Ok".

Then please run both of these commands and let me know the results:
cacls "C:\Program Files (x86)\Mozilla Firefox"
and
cacls "C:\Program Files (x86)\Mozilla Firefox\firefox.exe.update_in_progress.lock"

Thank you!

Flags: needinfo?(stecoop001-mozilla)

(In reply to Robin Steuber (they/them) [:bytesized] from comment #35)

How strange. It seems like even though Firefox's write check to the installation fails with Access Denied and the updater's attempt to open the Firefox binary also fails with Access Denied, the updater's attempt to open the lock file succeeds. I can't quite imagine why that would be.

Could you open the command prompt for me and send me the result of a couple of commands, please?

You can open the command prompt by pressing Win+R, typing cmd and hitting "Ok".

Then please run both of these commands and let me know the results:
cacls "C:\Program Files (x86)\Mozilla Firefox"
and
cacls "C:\Program Files (x86)\Mozilla Firefox\firefox.exe.update_in_progress.lock"

Thank you!

Below is a Copy And Paste of the results:

Microsoft Windows [Version 10.0.19045.3208]
(c) Microsoft Corporation. All rights reserved.

C:\Users\steco>cacls "C:\Program Files (x86)\Mozilla Firefox"
C:\Program Files (x86)\Mozilla Firefox <Account Domain not found>(OI)(CI)R
BUILTIN\Administrators:F
NT SERVICE\TrustedInstaller:(ID)F
NT SERVICE\TrustedInstaller:(CI)(IO)(ID)F
NT AUTHORITY\SYSTEM:(ID)F
NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(ID)F
BUILTIN\Administrators:(ID)F
BUILTIN\Administrators:(OI)(CI)(IO)(ID)F
BUILTIN\Users:(ID)R
BUILTIN\Users:(OI)(CI)(IO)(ID)(special access:)
GENERIC_READ
GENERIC_EXECUTE

                                   DATAMASTER-5\steco:(ID)F
                                   CREATOR OWNER:(OI)(CI)(IO)(ID)F
                                   APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(ID)R
                                   APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(OI)(CI)(IO)(ID)(special access:)
                                                                                                          GENERIC_READ
                                                                                                          GENERIC_EXECUTE

                                   APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(ID)R
                                   APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(OI)(CI)(IO)(ID)(special access:)
                                                                                                                     GENERIC_READ
                                                                                                                     GENERIC_EXECUTE

C:\Users\steco>cacls "C:\Program Files (x86)\Mozilla Firefox\firefox.exe.update_in_progress.lock"
The system cannot find the file specified.

C:\Users\steco>

Flags: needinfo?(stecoop001-mozilla)

Could I get the output of two similar but slightly different commands? Thanks!

icacls "C:\Program Files (x86)\Mozilla Firefox"
and
icacls "C:\Program Files (x86)\Mozilla Firefox\firefox.exe"

Flags: needinfo?(stecoop001-mozilla)

(In reply to Robin Steuber (they/them) [:bytesized] from comment #37)

Could I get the output of two similar but slightly different commands? Thanks!

icacls "C:\Program Files (x86)\Mozilla Firefox"
and
icacls "C:\Program Files (x86)\Mozilla Firefox\firefox.exe"

"Ask and ye shall receive":

Microsoft Windows [Version 10.0.19045.3208]
(c) Microsoft Corporation. All rights reserved.

C:\Users\steco>icacls "C:\Program Files (x86)\Mozilla Firefox"
C:\Program Files (x86)\Mozilla Firefox S-1-15-3-1024-1238444810-1356253261-2257478630-1143196962-1563090664-2414759320-1282101916-4218287853:(OI)(CI)(RX)
BUILTIN\Administrators:(F)
NT SERVICE\TrustedInstaller:(I)(F)
NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
BUILTIN\Users:(I)(RX)
BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
DATAMASTER-5\steco:(I)(F)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)
APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)
APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)

Successfully processed 1 files; Failed processing 0 files

C:\Users\steco>icacls "C:\Program Files (x86)\Mozilla Firefox\firefox.exe"
C:\Program Files (x86)\Mozilla Firefox\firefox.exe S-1-15-3-1024-1238444810-1356253261-2257478630-1143196962-1563090664-2414759320-1282101916-4218287853:(I)(RX)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Users:(I)(RX)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)

Successfully processed 1 files; Failed processing 0 files

C:\Users\steco>

Flags: needinfo?(stecoop001-mozilla)

Huh. Well apparently the key is this permission: DATAMASTER-5\steco:(I)(F). I can reproduce the problem if I change the permissions on my directory like this:

  1. Install an out-of-date copy of Firefox. Accept the installer UAC and install into the default location (the Program Files directory).
  2. Run Firefox and set app.update.service.enabled = true and app.update.staging.enabled = true (I'm not sure whether the latter is necessary). Close Firefox.
  3. Right click on the install directory and click Properties.
  4. Click the Security tab, then click Advanced.
  5. Click Change Permissions. Click Add.
  6. Click Select a Principal. Type the name of the current user. Click Check Names. Click OK.
  7. Make sure the the Full Control permission is checked. Change the Applies to drop down to This folder only.
  8. Click OK on all three open windows to close them.
  9. Reopen Firefox. Check for, download, and restart to install an update. This will fail as previously described.

If the permission gave the current user full control and was inheritable, the updater should be able to update Firefox without elevation because the files would be fully writable to the current user. I had thought that granting full control without inheritability to a directory would not actually allow the user to create a file in the directory, just to modify the directory itself. Because then you would create a file that you wouldn't actually have access to because it wouldn't inherit that permission.

However, clearly this understanding is incorrect. After having granted permission by following the steps above, I ran this from a regular, unelevated terminal:

> icacls /c/Program\ Files/Mozilla\ Firefox/
C:/Program Files/Mozilla Firefox/ S-1-15-3-1024-1238444810-1356253261-2257478630-1143196962-1563090664-2414759320-1282101916-4218287853:(OI)(CI)(RX)
                                  moz_bytesized\bytesized:(F)
                                  NT SERVICE\TrustedInstaller:(I)(F)
                                  NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
                                  NT AUTHORITY\SYSTEM:(I)(F)
                                  NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                                  BUILTIN\Administrators:(I)(F)
                                  BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
                                  BUILTIN\Users:(I)(RX)
                                  BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
                                  CREATOR OWNER:(I)(OI)(CI)(IO)(F)
                                  APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
                                  APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)
                                  APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)
                                  APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)

Successfully processed 1 files; Failed processing 0 files

> icacls /c/Program\ Files/Mozilla\ Firefox/firefox.exe
C:/Program Files/Mozilla Firefox/firefox.exe S-1-15-3-1024-1238444810-1356253261-2257478630-1143196962-1563090664-2414759320-1282101916-4218287853:(I)(RX)
                                             NT AUTHORITY\SYSTEM:(I)(F)
                                             BUILTIN\Administrators:(I)(F)
                                             BUILTIN\Users:(I)(RX)
                                             APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
                                             APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)

Successfully processed 1 files; Failed processing 0 files

> touch /c/Program\ Files/Mozilla\ Firefox/bytesized.test

> icacls /c/Program\ Files/Mozilla\ Firefox/bytesized.test
C:/Program Files/Mozilla Firefox/bytesized.test S-1-15-3-1024-1238444810-1356253261-2257478630-1143196962-1563090664-2414759320-1282101916-4218287853:(I)(RX)
                                                NT AUTHORITY\SYSTEM:(I)(F)
                                                BUILTIN\Administrators:(I)(F)
                                                BUILTIN\Users:(I)(RX)
                                                moz_bytesized\bytesized:(I)(F)
                                                APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
                                                APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)

Successfully processed 1 files; Failed processing 0 files

So apparently new files somehow can be created and can inherit this permission despite it being marked as not inheritable. Which is highly confusing to me. This permission situation seems reminiscent of Bug 1702276 to me, so I'm going to link these bugs. In both situations, we successfully create the update lock file but don't actually have the necessary permissions to update.

@Steven Cooper - Do you know how you ended up with this directory's permissions set that way? Both the BUILTIN\Administrators:(F) and the DATAMASTER-5\steco:(I)(F) permissions would not generally be there by default.

Flags: needinfo?(stecoop001-mozilla)
See Also: → 1702276

As I do not know what those permissions are, or how to change them, I have no answer.

I do have a special menu option in Explorer that allows me to "Take Ownership" of certain files and folders; I don't recall ever using it on the steco folder, though I may have used it on my entire C: drive.

What are these permissions, what should they be set to, and how do I set them?

Flags: needinfo?(stecoop001-mozilla)

(In reply to Steven Cooper from comment #40)

I do have a special menu option in Explorer that allows me to "Take Ownership" of certain files and folders; I don't recall ever using it on the steco folder, though I may have used it on my entire C: drive.

That would do it. I wouldn't really recommend setting your directory permissions that way. If any malware ever gets into your computer, having your permissions set like that will massively increase the scope of the damage it is capable of doing.

I can give you some instructions that I think will fix the update issue that you are currently having. But it's hard for me to be entirely sure because I don't think I fully understand the current system configuration.

  1. Right click on the install directory and click Properties.
  2. Click the Security tab, then click the Advanced button.
  3. Find the entry that lists the Principal as steco and select it.
  4. Click Remove.
  5. Click Ok to close both of the windows that are still open. It's likely that this will display an error message, but I don't think there is anything you can really do about it except dismissing it by pressing Cancel. It should still apply the changed permissions to the parent directory, just not to the contents.

It's possible that the next time that you update successfully, it may cause the installation directory to re-inherit the permissions causing the problem to return. You might be able to prevent this from happening by repeating the above steps on the parent of the installation directory (C:\Program Files (x86)), which really shouldn't have that permission anyways.

I am going to downgrade the severity of this bug. I don't think it can happen without an unusual permission configuration. I don't think that this is a common enough situation to warrant prioritizing this bug.

Severity: S2 → S3
Summary: Updater not escalating privileges via UAC when it ought to → Updater fails to escalate privileges as needed if the install directory permissions grant the user full control but are not inheritable

(In reply to Robin Steuber (they/them) [:bytesized] from comment #41)

(In reply to Steven Cooper from comment #40)

I do have a special menu option in Explorer that allows me to "Take Ownership" of certain files and folders; I don't recall ever using it on the steco folder, though I may have used it on my entire C: drive.

That would do it. I wouldn't really recommend setting your directory permissions that way. If any malware ever gets into your computer, having your permissions set like that will massively increase the scope of the damage it is capable of doing.

I can give you some instructions that I think will fix the update issue that you are currently having. But it's hard for me to be entirely sure because I don't think I fully understand the current system configuration.

  1. Right click on the install directory and click Properties.
  2. Click the Security tab, then click the Advanced button.
  3. Find the entry that lists the Principal as steco and select it.
  4. Click Remove.
  5. Click Ok to close both of the windows that are still open. It's likely that this will display an error message, but I don't think there is anything you can really do about it except dismissing it by pressing Cancel. It should still apply the changed permissions to the parent directory, just not to the contents.

It's possible that the next time that you update successfully, it may cause the installation directory to re-inherit the permissions causing the problem to return. You might be able to prevent this from happening by repeating the above steps on the parent of the installation directory (C:\Program Files (x86)), which really shouldn't have that permission anyways.

I am going to downgrade the severity of this bug. I don't think it can happen without an unusual permission configuration. I don't think that this is a common enough situation to warrant prioritizing this bug.

THAT WORKED!!! 8-))

I just updated to 115.0.3 and all went exactly as it should.
A note about your instructions...I had to click on "Disable Inheritences" before I could remove the 'steco' entry; that disabled inheritences for all the principles. I'm going to do some more research about this issue; I remember now why I took ownership of the Program Files (x86)...I wanted to manually install a program in that folder and Windows wouldn't let me. All this bloody security is really getting annoying...I miss my DOS days.

Thank you for your help and walking me through the solution; the original bug (Bug 1838567 - Bookmark Problem) remains, but I can live with it.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: