MSI installer strips inherited "ALL APPLICATION PACKAGES" ACE from install directory

Offen
#63,590 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
72/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
node.js
Bereich
build-system

Rechercherichtung

Beginne in tools/msvs/msi/nodemsi/product.wxs bei der Komponente SetInstallDirPermission und vergleiche dann die resultierende ACL mit den icacls-Beispielen im Issue. Prüfe das Verhalten von WiX 4 Permission und PermissionEx und setze den vorgeschlagenen ACL-Ansatz um. Als erledigt gilt die Aufgabe, wenn ein installiertes C:\Program Files\nodejs-Verzeichnis einen ACE für ALL APPLICATION PACKAGES mit Lese-/Ausführungsberechtigung behält, ohne die erforderlichen vorhandenen Berechtigungen zu entfernen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

stale

MSI installer strips inherited "ALL APPLICATION PACKAGES" ACE from install directory

Description

The Windows MSI installer sets an explicit DACL on C:\Program Files\nodejs via the SetInstallDirPermission component in product.wxs, which replaces the inherited ACL from C:\Program Files. This removes the ALL APPLICATION PACKAGES (SID S-1-15-2-1) ACE that is normally inherited by all subdirectories under C:\Program Files.

Current behavior

The WiX <Permission> element maps to the MSI LockPermissions table, which replaces the entire DACL rather than merging with inherited ACEs. The current configuration only grants access to four principals:

<Component Id="SetInstallDirPermission" Guid="{EFFC4F74-183A-4237-BBD7-0CAD2B950053}">
  <CreateFolder>
    <Permission User="[WIX_ACCOUNT_USERS]" GenericRead="yes" Traverse="yes" GenericExecute="yes" Synchronize="yes"
                GenericWrite="no" WriteAttributes="no" WriteExtendedAttributes="no"/>
    <Permission User="[AUTHENTICATED_USERS]" GenericRead="yes" Traverse="yes" GenericExecute="yes" Synchronize="yes"
                GenericWrite="no" WriteAttributes="no" WriteExtendedAttributes="no"/>
    <Permission User="[WIX_ACCOUNT_ADMINISTRATORS]" GenericAll="yes"/>
    <Permission User="[WIX_ACCOUNT_LOCALSYSTEM]" GenericAll="yes"/>
  </CreateFolder>
</Component>

You can verify this by comparing the ACLs:

# Other Program Files subdirectories have ALL APPLICATION PACKAGES
icacls "C:\Program Files\dotnet"
# ... APPLICATION PACKAGES:(OI)(CI)(RX) ...

# Node.js does not
icacls "C:\Program Files\nodejs"
# Only shows Users, Authenticated Users, Administrators, SYSTEM

Expected behavior

The nodejs directory should have the same ALL APPLICATION PACKAGES read/execute ACE that other C:\Program Files subdirectories inherit, allowing AppContainer-sandboxed processes to access Node.js.

Impact

Processes running in an AppContainer sandbox (e.g., UWP apps, sandboxed browser processes, and other packaged applications) cannot read or execute files under C:\Program Files\nodejs. This can cause failures when sandboxed processes need to invoke node.exe or resolve Node.js modules.

Suggested fix

Replace the <Permission> elements (which use the LockPermissions table and replace the DACL) with <PermissionEx> using an SDDL string that includes the ALL APPLICATION PACKAGES SID, or add a <Permission> entry for ALL APPLICATION PACKAGES. For example, using SDDL:

<CreateFolder>
  <PermissionEx Sddl="D:PAI(A;OICI;GRGX;;;BU)(A;OICI;GRGX;;;AU)(A;OICI;GA;;;BA)(A;OICI;GA;;;SY)(A;OICI;GRGX;;;AC)" />
</CreateFolder>

Where AC is the well-known SDDL abbreviation for ALL APPLICATION PACKAGES (S-1-15-2-1).

Environment

  • OS: Windows 10/11
  • Installer: MSI (WiX 4)
  • Introduced in: WiX 4 migration (PR #45943), though the same issue likely existed in WiX 3
Vorherrschende Sprache
JavaScript
Sterne
122k
Forks
37.4k
Ø Merge
4 T. 4 Std.
Gemergte PRs (30 T.)
276

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus nodejs/node

Alle Issues in nodejs/node

Ähnliche Issues

Weitere Issues zu JavaScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.