The npm community forum has been discontinued.
To discuss usage of npm, visit the GitHub Support Community.
root-owned files in cache folder
Putting this here mostly as a placeholder, and I’ll probably spin it into a post in the #ideas category as well.
As mentioned in Release: firstname.lastname@example.org by @godmar, there are still some cases where a root-owned file ends up in the npm cache if you use
sudo. I’ve identified 3 cases now, and the fact that cache file writing is spread out is kind of not ideal (that’s the #ideas bit). For the next v6, I intend to fix this somewhat tactically, just to get around the issue, but there’s some more strategic cleanup that could be done.
- Pacote doesn’t always pass uid/gid options to
Part of this was identified in https://github.com/zkat/pacote/issues/174, but it’s fixed more thoroughly in https://github.com/npm/pacote/commit/3d08925ade56efb9b94e29ad3c882f4044c79b1d. Pacote 9.5.2 will be in the next npm v6 release.
- We also write a file to the cache for metrics, which will be root owned when run as root.
- Lastly, we write a file to the cache for debug logs, which will result in a root-owned cache folder (!!) if the cache doesn’t already exist.
Like I said above, I intend to fix this somewhat surgically with the next v6 release, but it seems like we have a need for a “create a file/folder and preserve the dir tree ownership”, which starts to feel to me like a standalone module. I’m not sure.
I said so in 7770
Also, https://github.com/npm/pacote/commit/3d08925ade56efb9b94e29ad3c882f4044c79b1d is not a fix because it lacks tests. The lack of tests is what got you in this situation in the first place.
Full test coverage for pacote is on my todo list.
there might be a conceptual problem in npm in general. npm is not designed to be an operating system package manager. by setting file permissions it interferes with security policies operating systems try to impose. a pointer advocating “the one who creates the file should be the owner, do the rest with ACL, otherwise you have a security hole”: https://unix.stackexchange.com/questions/99079/setting-default-username-and-group-for-files-in-directory
the solution seems simple, for Linux: set an ACL to the concerned directories which allows the users primary group full access to user specific directories, and make global directories world readable. instead of changing the user of every single file and directory, or change a whole trees ownership.
the ACL should only be set if npm creates the directory to not override what the user or the operating system package manager did beforehand. e.g. for the users _cacache this might look like, in bash syntax:
$ mkdir .npm/_cacache $ mygroup=`id -gn` $ setfacl -m g:$mygroup:rwX .npm/_cacache $ setfacl -d -m g:$mygroup:rwX .npm/_cacache
note the capital X to set the execution bit the same way as the folder or file has originally. this can be done by the operating system package on install. or - by the user itself. or - when npm runs and creates a folder, it can set the ACL like this.
global directories can be made group and world readable, e.g. node_modules:
# mkdir /usr/lib/node_modules/ # mygroup=`id -gn` # sudo setfacl -d -m o:rX /usr/lib/node_modules/ # sudo setfacl -d -m g:root:rX /usr/lib/node_modules/
this might be a duplicate of:
to set the same executable permission on group and other, and to make it group and other readable currently i run, after installing “ungit” e.g.:
sudo -H npm install -g ungit sudo find /usr/lib/node_modules/ungit/ -perm /u+r -print0 | sudo xargs -0 chmod a+r sudo find /usr/lib/node_modules/ungit/ -perm /u+x -print0 | sudo xargs -0 chmod a+x