3 ms·

Well yes, if you're running as a privileged user and you install a package globally, it can install global binaries. Don't install packages you can't trust.

imtringued 7y ago
That eliminates almost all NPM packages.
- tomxor 7y ago
  Yes exactly, which is why npm's default root prefix is a poor choice, see my other comment for a slightly safer alternative.
  - inimino 7y ago
    No, it's not. If you want to install a package like babel or webpack, or npm itself, and you want it to install manpages and commands like any real Unix program, you want it in /usr/local, and this is exactly what /usr/local is for. These are the usecases that -g is for, and that's the only thing it's for: utilities that you want to add to your system, not mere runtime JS dependencies. NPM has this feature because in the beginning people (including me) wanted it to be more than just a manager for JS files under a build directory, because we were using it to build shared useful utilities, not just runtime dependencies. This is a problem that has played out again and again with every programming language that has its own package installer, because setting the boundaries and interacting with the host system correctly while satisfying everyone's needs is challenging.
    - tomxor 7y ago
      Using ~/.local gives you all those things without giving root access, there is no good reason to stick everything in /usr/local especially with something like npm which is wide open for anyone to publish anything instantly.
      - inimino 7y ago
        Yes, and then the question is, should you be putting programs you don't trust at all in your PATH?
        tomxor 7y ago
        Yes, if i trust them enough to add and not replace binaries.
        inimino 7y ago
        But once you run any of those binaries, it's free to replace any of your other (non-root-owned) binaries in `~/.local`. So the trust you're talking about seems to be a preference, but I don't think there's any particularly plausible threat model that makes one of these safer than the other.
- inimino 7y ago
  Indeed it does.

imtringued 7y ago

That eliminates almost all NPM packages.

tomxor 7y ago
Yes exactly, which is why npm's default root prefix is a poor choice, see my other comment for a slightly safer alternative.
- inimino 7y ago
  No, it's not. If you want to install a package like babel or webpack, or npm itself, and you want it to install manpages and commands like any real Unix program, you want it in /usr/local, and this is exactly what /usr/local is for. These are the usecases that -g is for, and that's the only thing it's for: utilities that you want to add to your system, not mere runtime JS dependencies. NPM has this feature because in the beginning people (including me) wanted it to be more than just a manager for JS files under a build directory, because we were using it to build shared useful utilities, not just runtime dependencies. This is a problem that has played out again and again with every programming language that has its own package installer, because setting the boundaries and interacting with the host system correctly while satisfying everyone's needs is challenging.
  - tomxor 7y ago
    Using ~/.local gives you all those things without giving root access, there is no good reason to stick everything in /usr/local especially with something like npm which is wide open for anyone to publish anything instantly.
    - inimino 7y ago
      Yes, and then the question is, should you be putting programs you don't trust at all in your PATH?
      - tomxor 7y ago
        Yes, if i trust them enough to add and not replace binaries.
        inimino 7y ago
        But once you run any of those binaries, it's free to replace any of your other (non-root-owned) binaries in `~/.local`. So the trust you're talking about seems to be a preference, but I don't think there's any particularly plausible threat model that makes one of these safer than the other.
inimino 7y ago
Indeed it does.