Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
#63,590 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
72/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
node.js
Domaine
build-system

Piste de recherche

Commencez dans tools/msvs/msi/nodemsi/product.wxs, au niveau du composant SetInstallDirPermission, puis comparez l’ACL résultante avec les exemples icacls de l’issue. Examinez le comportement de Permission et PermissionEx dans WiX 4 et appliquez l’approche ACL suggérée. C’est terminé lorsqu’un répertoire C:\Program Files\nodejs installé conserve une ACE de lecture/exécution pour ALL APPLICATION PACKAGES sans supprimer les autorisations existantes requises.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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
Langage dominant
JavaScript
Étoiles
122k
Forks
37.4k
Merge moyen
4 j 3 h
PR mergées (30 j)
279

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de nodejs/node

Toutes les issues de nodejs/node

Issues similaires

Plus d'issues JavaScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.