You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Mac Installer: npm and npx created with wrong permissions #57548
changed the title [-]Mac Installer: npm and npx symlinks created with wrong permissions[/-][+]Mac Installer: npm and npx created with wrong permissions[/+]on Mar 20, 2025
I am not sure where your hostile attitude comes from, but I hope you are having a nice day.
Currently, the NodeJS installer respects the umask configured for users apps only for npm and npx—for all other files including the node and corepack binaries it does not:
$ ls -la /usr/local/bin/{corepack,node,npm,npx}
lrwxr-xr-x 1 root wheel 45 Mar 19 16:55 /usr/local/bin/corepack -> ../lib/node_modules/corepack/dist/corepack.js
-rwxr-xr-x 1 root wheel 220243216 Feb 11 05:31 /usr/local/bin/node
[…] sets the user's umask for every app they open, including apps they access from the command line and new files that those apps create.
Yes, an installer is an app, so one might argue that it should respect the umask for user apps.
On the other hand, one could argue that an installer is a special kind of app.
The NodeJS installer only supports System-wide installation.
Therefore, the installed binaries should have read and execute permissions for owner, group, and other so that they are accessible System-wide, i.e. by all users.
This is inconsistent: It should either respect the umask configured for users apps for all files or none.
npm, npx and corepack are all created the exact same way.
I suspect you installed multiple versions over each other. Note how the timestamps and group names are different.
Apropos umask: if someone wants to install node and cut out group or other, they should be able to. You don't like what it did to your local install but that's entirely self-inflicted, it's classic PEBKAC.
I think it's worth asking the question whether this postinstall script is still needed, if the installer installs corepack correctly without the postinstall script, chances are it would also install npm and npx correctly.
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Activity
[-]Mac Installer: npm and npx symlinks created with wrong permissions[/-][+]Mac Installer: npm and npx created with wrong permissions[/+]sdavids commentedon Mar 20, 2025
This is especially bad because
/usr/localis protected by System Integrity Protection.To fix it one has to:
sudo chmod ugo+rx /usr/local/bin/{npm,npx}in Recovery modebnoordhuis commentedon Mar 25, 2025
It's doing exactly what you told it to, right? Don't change your umask if you don't want that.
It's like the old joke about a man who goes to visit his MD. "Doc, it bleeds when I cut myself." "Then stop doing that!"
sdavids commentedon Mar 25, 2025
I am not sure where your hostile attitude comes from, but I hope you are having a nice day.
Currently, the NodeJS installer respects the umask configured for users apps only for
npmandnpx—for all other files including thenodeandcorepackbinaries it does not:This is inconsistent: It should either respect the umask configured for users apps for all files or none.
Let’s see what the docs say:
Set a custom umask in macOS — Umask for user apps
Yes, an installer is an app, so one might argue that it should respect the umask for user apps.
On the other hand, one could argue that an installer is a special kind of app.
The NodeJS installer only supports System-wide installation.
Therefore, the installed binaries should have read and execute permissions for owner, group, and other so that they are accessible System-wide, i.e. by all users.
sdavids commentedon Mar 25, 2025
One can also set the unmask for system processes but that should not be used by an installer either.
bnoordhuis commentedon Mar 25, 2025
npm, npx and corepack are all created the exact same way.
I suspect you installed multiple versions over each other. Note how the timestamps and group names are different.
Apropos umask: if someone wants to install node and cut out group or other, they should be able to. You don't like what it did to your local install but that's entirely self-inflicted, it's classic PEBKAC.
sdavids commentedon Mar 25, 2025
They are not.
No, the installer is responsible.
All files are copied with the correct permissions, but the
postinstallscript creates the symlinks with the wrong permissions.That is why everything is fine exept for the
npmandnpxsymlinks.A fix would be:
aduh95 commentedon Mar 29, 2025
I think it's worth asking the question whether this
postinstallscript is still needed, if the installer installscorepackcorrectly without the postinstall script, chances are it would also installnpmandnpxcorrectly.sdavids commentedon Mar 30, 2025
corepackis part of the node pkg whereas thenpmandnpxsymlinks are created via the postinstall script.Notice the unlink, maybe it should be changed to:
tools: delete macos installer postinstall script
sdavids commentedon Mar 30, 2025
see #57661 (comment)
github-actions commentedon Apr 20, 2026
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
github-actions commentedon May 21, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
sdavids commentedon May 21, 2026
Still relevant.