zkat / cacache

💩💵 but for your data. If you've got the hash, we've got the cache ™ (moved)

Home Page:https://github.com/npm/cacache

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

How does cacache behave while running under sudo on Linux?

godmar opened this issue · comments

I searched for 'sudo' under open and closed issues, didn't get any hits.

Put briefly, running npm install -g or npm upgrade -g under sudo on Unix-like platforms such as OSX or Linux does not work because npm in this case write files using the effective uid (root/root) in the invoking user's ${HOME}/.npm/_cacache directory. Subsequently, operations that do not use sudo fail and require the user to adjust the permissions. This appears to be a well-known issue, for instance, here is the first Google hit for sudo npm.

I've looked at various issues for npm, some referring to a package called pacote, some referring to cacache. Since the permission errors occur in such directories as ~/.npm/_cacache/... I'm filing this issue here, fully realizing it may be an issue with whoever uses cacache.

I should point out I find this issue very annoying. A typical sequence is:

  • install node/npm via instructions linked from node.js page
  • when running an npm command, receive a notification that an update to npm is available.
  • then, run the update command via sudo
  • end up with a permission-corrupted cache that requires me to restore permissions

A naive solution would be to not write to ${HOME}/.npm/_cacache when running under euid == 0, but who exactly would be in charge of enforcing this? (Caveat: I have not looked at your code.)

Thanks for any help/insight you can provide.

Since npm/cli does not have an issue tracker, I hope it's ok if I share some of my sleuthing here in the hopes that it helps with finding a fix.
Starting with npm's config/default.js (see here) it appears that npm uses $HOME to determine its cache location. Therefore, it must either drop privileges to process.env.SUDO_UID or use some kind of chown post-writing. I'm trying to find out where.

cache.js includes two packages (pacote and this one (cacache)), but it's not quite clear where the cache is accessed. Could it be here, on line 131.
There, unpack is called with what includes a uid/gid parameter. I am having trouble finding where cache.js is required in npm.

How does npm relay the fact that it's running under sudo to pacote/cacache (which are responsible for writing to the user's $HOME/.npm/_cacache with wrong permissions?

I think cache.js is the wrong file to look at; this file appears to just implemented the npm cache command.
The problem occurs on the npm install path.

Specifically, files such as action/fetch.js (see here) access a file called figgy-config.js (here) which does include numeric versions of the correct user's uid/gid in the config object it returns. See here.

So, how do we get from there to the corruption in ${HOME}/.npm/_cacache? Upon closer inspection, I note that it's one of the index directories that's wrong. This code seems to be part of cacache, specifically in this file, entry-index which appears to try to change the created directory's uid/gid if opts.uid/opts.gid is provided (which would somehow be passed down from npm as outlined above...). It may be time to stop trying to trace the code and debug the actual values that appears in the code.

It appears that pacote fails to pass on the necessary options. For instance, pacote calls cacache.put here and discards opts.uid:

          // opts.uid is disregarded here, resulting in cacache setting wrong permissions
          return cacache.put(
            opts.cache, cacheKey, '.', {
              metadata: {
                id: manifest._id,
                manifest,
                type: 'finalized-manifest'
              }
            }

I'll track down the other paths and then file an issue with pacote

Closing this in favor of pacote issue #74

Does this explain the reason why I can't .get on my dev machine (Linux) and also why the files in the ./cache-path/content-v5/sha512/<some-number>/* are having padlocks on them (permission issues)??