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
Summary: process.umask() (no args) will be deprecated and removed.
I couldn't quite divine what lib/config/defaults.js uses process.umask() for but in most cases you don't need to deal with the umask directly - the operating system will apply it automatically.
Since this is only done after the file is created (and it is created without the knowledge that it will eventually need to be an executable script), we can't just rely on default file creation masking, since chmod isn't limited by that.
If we don't read process.umask, we risk making all executable files world-writable (or even just group-writable) which is a security risk.
As I can see it, the only way to avoid this would be to have pacote take note of executable file targets at unpack time, and create them with a 0o777 mode, regardless of what the archive entry says, and then also tell tar not to chmod them to 0o777 after creation.
Probably this will require a way to provide chmod:false to tar.Unpack anyway, so that pacote can just set the creation modes to 0o666/0o777 and ignore the specific mode found in the archive.
Re npm/cli#1103
Currently we use the
process.umask()
value to determine the appropriate mode for executable files on the system.Since this is only done after the file is created (and it is created without the knowledge that it will eventually need to be an executable script), we can't just rely on default file creation masking, since chmod isn't limited by that.
If we don't read process.umask, we risk making all executable files world-writable (or even just group-writable) which is a security risk.
As I can see it, the only way to avoid this would be to have pacote take note of executable file targets at unpack time, and create them with a
0o777
mode, regardless of what the archive entry says, and then also tell tar not to chmod them to 0o777 after creation.Probably this will require a way to provide
chmod:false
totar.Unpack
anyway, so that pacote can just set the creation modes to 0o666/0o777 and ignore the specific mode found in the archive.cc: @bnoordhuis
The text was updated successfully, but these errors were encountered: