Skip to content

Shortcircuit userCanElevate in the updater

Normally we disable every possibility of elevation, however I found one check we don't patch:

diff --git a/toolkit/mozapps/update/UpdateService.sys.mjs b/toolkit/mozapps/update/UpdateService.sys.mjs
index b08fecbc9184..1c2742afe081 100644
--- a/toolkit/mozapps/update/UpdateService.sys.mjs
+++ b/toolkit/mozapps/update/UpdateService.sys.mjs
@@ -815,9 +815,9 @@ function getCanApplyUpdates() {
       // accepting a UAC prompt from an elevation request made by the updater.
       // Whether the client can elevate (e.g. has a split token) is determined
       // in nsXULAppInfo::GetUserCanElevate which is located in nsAppRunner.cpp.
-      let userCanElevate = Services.appinfo.QueryInterface(
-        Ci.nsIWinAppHelper
-      ).userCanElevate;
+      let userCanElevate =
+        !AppConstants.BASE_BROWSER_UPDATE &&
+        Services.appinfo.QueryInterface(Ci.nsIWinAppHelper).userCanElevate;
       if (lazy.gIsBackgroundTaskMode) {
         LOG(
           "getCanApplyUpdates - in background task mode, assuming user can't elevate"

So, I don't think this is harmful, except that the updater might mistakenly think it can update Tor Browser because the user could elevate, but as a matter of fact any code to do so is disabled.

So, I see this as an improvement for error reporting, rather than a bug/lack on our side.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information