1733284 - LaunchUnelevated fails with packaged app on Windows 10

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

If Firefox is run with an elevated integrity level (for instance from an elevated installer such as Fiddler Classic), the launcher process will attempt to relaunch it unelevated by re-running the .exe through the shell. This won't work if Firefox is installed as an MSIX package, there is no permission for anyone to directly execute the .exe within the package's VFS (to prevent issues like bug 1732907), so there is an error "Windows cannot access the specified device, file, or path" from Explorer.

In a package context, we should give Explorer the path to the Firefox app within the package as shell:appsFolder\<Package Family Name>\FIREFOX instead of using the .exe name.

This was observed above on Windows 10 21H1 (19043.1202). It doesn't seem to occur on the latest Windows 11 beta (22000.194). Here, we still LaunchUnelevated(), but it seems that Explorer (or CreateProcess) is able to figure out what to do when given the path of the packaged exe that doesn't have normal execute permissions. The launched Firefox does have the proper package identity.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Installer' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Bug 1731261 may be related to this, though maybe not since it shows no error message and that issue occurs on Windows 11.

Comment 3

[Robin Steuber (they/them) [:bytesized]]

Setting S3 severity since there seems to be a pretty clear workaround.

Comment 4

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

While a lot of MSIX bugs are in Firefox::Installer, this is about the launch unelevated functionality, which doesn't have much to do with the installation of Firefox.

Comment 5

[Nick Alexander :nalexander [he/him]]

Attachment: Bug 1733284: Part 1: Expose Windows packaged app utilities to code outside of XUL. r?mhowell!

This re-arranges some deckchairs, allowing to have the launcher
process query the Windows packaged app environment.

Depends on D129882

Comment 6

[Nick Alexander :nalexander [he/him]]

Ben is going to push this forward.

Comment 7

[[e-mail] (:bhearsum)]

Attachment: Bug 1733284: Part 2: Re-launch Firefox with an App path when running in a package context r=mhowell!

Depends on D130187

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ef5af0d19429
Part 1: Expose Windows packaged app utilities to code outside of XUL. r=mhowell
https://hg.mozilla.org/integration/autoland/rev/00e04ec76768
Part 2: Re-launch Firefox with an App path when running in a package context r=mhowell,tkikuchi

Comment 9

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/ef5af0d19429
https://hg.mozilla.org/mozilla-central/rev/00e04ec76768

Comment 10

[Catalin Sasca, Desktop QA [:csasca]]

Reproduced the issue on Windows 10 with 96.0a1 (2021-11-17). We verified the fix for 96.0a1 (2021-11-18) on two different systems on both Windows 10 and 11 by using the STR from Bug 1731261. Please let me or atrif know if we need to do additional testing here.