Closed Bug 1830071 Opened 1 year ago Closed 6 months ago

Background Update Task Doesn't Run if User Who Installed FF Doesn't Log in

Categories

(Toolkit :: Application Update, defect, P3)

Firefox 112
defect

Tracking

()

RESOLVED FIXED
123 Branch
Tracking Status
firefox-esr115 --- wontfix
firefox123 --- fixed

People

(Reporter: mwiditor, Assigned: nshukla)

References

Details

(Whiteboard: [fidedi-ope])

Attachments

(2 files)

Attached image Capture.PNG

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

Steps to reproduce:

Install Firefox on Windows 10 using User A (in my case SYSTEM), never log into that account. Have User B log in and use computer as normal, but not use Firefox. Wait a month or so for Firefox updates to become available. Check windows Task Scheduler to see if "Firefox Background Update" has ever successfully ran. Check version of Firefox in "Add or remove programs".

Actual results:

Firefox Background Update task never runs, resulting in an out of date and vulnerable installation of Firefox. See in Windows Task Scheduler that the Firefox Background Update task is set to "run only when user is logged in" but that user never logs in.

Expected results:

The Firefox Background Update task should run when any user is logged in, not just the user who installed Firefox, regardless of whether they regularly use Firefox.

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

Hello and thank you for filing a bug.

My understanding of how this ought to work is that each user (that runs Firefox) would have their own scheduled task to run background update so that it would run as the current user when that user is logged in. But I can see from trying this out locally, that that does not happen. In fact, my own installation was actually stuck in pretty much the exact situation described in Comment 0 without me ever realizing it.

I didn't delve quite deep enough to get the Windows error code (we just return an NS_ERROR_FAILURE), but I can see that when the task has already been created by another user, we fail to create it as the the current user. And then if I delete the other user's task, it now succeeds.

Just to add another layer of annoyance into this whole situation, even though we cannot create a scheduled task with a name that conflicts with one created by another user, nsWinTaskSchedulerService::GetFolderTasks does not see tasks created by other users.

@nalexander - I wanted to double check that my understanding of how this ought to work (one task per user) matches with your understanding. Any thoughts on how this situation should be resolved?

Flags: needinfo?(nalexander)

@nalexander would there be someone else who has this information?

Whiteboard: [fidedi-ope]
Duplicate of this bug: 1843301
Severity: -- → S3
Priority: -- → P3
Assignee: nobody → nshukla
Attachment #9358941 - Attachment description: WIP: Bug 1830071 - Ensure tasks run across all users in Windows r=bytesized,nrishel → Bug 1830071 - Ensure tasks run across all users in Windows r=bytesized,nrishel
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

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

Hello and thank you for filing a bug.

My understanding of how this ought to work is that each user (that runs Firefox) would have their own scheduled task to run background update so that it would run as the current user when that user is logged in. But I can see from trying this out locally, that that does not happen. In fact, my own installation was actually stuck in pretty much the exact situation described in Comment 0 without me ever realizing it.

I didn't delve quite deep enough to get the Windows error code (we just return an NS_ERROR_FAILURE), but I can see that when the task has already been created by another user, we fail to create it as the the current user. And then if I delete the other user's task, it now succeeds.

Just to add another layer of annoyance into this whole situation, even though we cannot create a scheduled task with a name that conflicts with one created by another user, nsWinTaskSchedulerService::GetFolderTasks does not see tasks created by other users.

@nalexander - I wanted to double check that my understanding of how this ought to work (one task per user) matches with your understanding. Any thoughts on how this situation should be resolved?

Sorry for completely missing this as it went by moons ago. What you describe is exactly how this task should work: one task per user. I was simply not aware that the namespace of tasks was global and not per-Windows OS user.

I'll review Nipun's patches now.

Flags: needinfo?(nalexander)
Pushed by nshukla@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1de28867d67c
Ensure tasks run across all users in Windows r=bytesized,application-update-reviewers,nalexander
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → 123 Branch

Is this upliftable to the ESR?

It appears to graft cleanly. I see that TASK_DEF_CURRENT_VERSION = 3; on ESR currently, so there should be no problems, say, skipping a version via the uplift and then not task changes not being updated when the they make it to ESR via the trains. I think it would be a fairly low risk uplift.

@mkaply I take it that you think this ought to be uplifted?

Flags: needinfo?(mozilla)

Yes, please.

Flags: needinfo?(mozilla)

I chatted with Nipun and he's going to take care of this uplift.

Comment on attachment 9358941 [details]
Bug 1830071 - Ensure tasks run across all users in Windows r=bytesized,nrishel

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Before fixing this bug, it wasn't possible to have updater tasks across multiple users on the same installation of Windows. Being able to support this is especially relevant to the kind of environments where ESR is most commonly used.
  • User impact if declined: Updater tasks will continue to be non-functional if multiple accounts exist on the computer. If the Windows account with the registered task is not logged into, background updates will not be delivered.
  • Fix Landed on Version: 123
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): There is a chance of negatively affecting existing updater tasks as they are migrated to the new task definition format however migration has been tested enough that the chances of this happening are low.
Attachment #9358941 - Flags: approval-mozilla-esr115?

Comment on attachment 9358941 [details]
Bug 1830071 - Ensure tasks run across all users in Windows r=bytesized,nrishel

Approved for ESR, thanks.

Attachment #9358941 - Flags: approval-mozilla-esr115? → approval-mozilla-esr115+

Please verify that patches actually work on the target branch before requesting uplift , thanks.

Flags: needinfo?(nshukla)

I rebased it onto ESR locally and was able to build without issues which is why I thought it would work. I'm looking into this now.

Flags: needinfo?(nshukla)

Are you still looking into this?

Flags: needinfo?(nshukla)

Something else came up and this completely slipped my mind. If I recall correctly there was an issue with it grafting that I couldn't really resolve.

Flags: needinfo?(nshukla)

This is the failure the builds hit, fwiw:

ERROR -  /builds/worker/checkouts/gecko/toolkit/components/taskscheduler/nsWinTaskScheduler.cpp(128,38): error: use of undeclared identifier 'GetCurrentProcessToken'
 INFO -    BOOL success = GetTokenInformation(GetCurrentProcessToken(), TokenUser,
 INFO -                  

https://treeherder.mozilla.org/logviewer?job_id=452944461&repo=try&lineNumber=29389

Some older Rust crate on ESR or something causing problems maybe?

See Also: → 1891521
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: