Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
#63,590 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
node.js
Ambito
build-system

Direzione di ricerca

Inizia in tools/msvs/msi/nodemsi/product.wxs, nel componente SetInstallDirPermission, quindi confronta l’ACL risultante con gli esempi di icacls nell’issue. Esamina il comportamento di Permission e PermissionEx in WiX 4 e applica l’approccio ACL suggerito. Il lavoro è completato quando una directory C:\Program Files\nodejs installata conserva una ACE di lettura/esecuzione per ALL APPLICATION PACKAGES senza rimuovere le autorizzazioni esistenti richieste.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
JavaScript
Stelle
122k
Fork
37.4k
Merge medio
4g 4h
PR unite (30g)
276

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nodejs/node

Tutte le issue di nodejs/node

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.