5 ms·

The fact that "bin" files of globally installed dependencies can overwrite each other silently - it's an understandable oversight, and I'll be glad if npm/yarn

The fact that "bin" files of globally installed dependencies can overwrite each other silently - it's an understandable oversight, and I'll be glad if npm/yarn notifies me in the future. What surprised me was that the "bin" names can be a relative or absolute path, like: "bin": { "/usr/bin/date": "./fake-date" } That is scary! I'm guessing these paths will be sanitized in the newest versions of package managers, but that seems like it was a pretty big security hole. As others have commented, I prefer not to install things globally - mostly locally linked packages of my own. I believe projects should not require or recommend globally installed commands, everything it needs for building should be in its local node_modules folder.

inimino 7y ago
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.
tomxor 7y ago
> What surprised me was that the "bin" names can be a relative or absolute path, like: > "bin": { "/usr/bin/date": "./fake-date" } This will only possibly work if you install it with root privileges... at which point you need to have a reasonable level of trust of the script you are running. It's unreasonable to give the same level of trust to npm packages that you do your OS package manager since anyone can publish an npm package without anyone elses permission. For this reason I think npm's defaults are a really shitty choice (global prefix under root). I always change the global prefix to live in my user directory for this reason so I can npm install -g without root: sudo npm config -g set prefix '~/.local' You will need to add the local bin to your PATH (if it doesn't already contain it) PATH="$HOME/.local/bin:$PATH" The order above is important, local must come before existing PATHs for lower precedence so that it cannot override higher privilege bins... e.g so that if an npm package added a bin for '~/.local/bin/cat', it would never be called implicitly since '/usr/bin/cat' exists.
- ryukafalz 7y ago
  >The order above is important, local must come before existing PATHs for lower precedence so that it cannot override higher privilege bins You've got the order reversed there - the first item found in your PATH will be used, and therefore earlier directories in your PATH have higher precedence: jfred@lambdacrypt ~$ cat dir1/pathtest #!/run/current-system/profile/bin/bash echo "script in dir1" jfred@lambdacrypt ~$ cat dir2/pathtest #!/run/current-system/profile/bin/bash echo "script in dir2" jfred@lambdacrypt ~$ PATH=$HOME/dir1:$HOME/dir2 pathtest script in dir1
  - tomxor 7y ago
    You are correct my mistake.
- inimino 7y ago
  I don't understand the point in using ~/.local/bin and then putting it in your PATH. The point of treating /usr/local/bin and the other root-owned binary directories specially is that they are in your path, which means that if you type "ls" you want to run "ls" and not something untrusted. For that reason, anything you put in your PATH needs to be treated exactly with as much care as anything you install in /bin. The only difference might be that you don't affect other users on the same system, in a multi-user environment (which is increasingly rare). It might be convenient if you wanted to be able to clean up an entire installation by deleting one directory, but it's not a security feature. Don't install binaries anywhere in your path if you don't trust them or know where they came from. (Also, sibling is correct that first location found wins when searching PATH for a command name.) Also, it's not unreasonable to trust npm packages just like OS packages if you know who released it. NPM names are first-come, first-served, and once allocated, they are permanent. If you know and trust the person who released the package, there's nothing wrong with trusting the package. This was, in fact, the norm when npm was new and the community was small and most people knew each other. The only problem is with treating npm like a vetted distro like Debian, and assuming that anything on npm is safe to install without any connection to the author (or 1001 dependencies). That's where everything started to go sideways.
SamHasler 7y ago
> I'll be glad if npm/yarn notifies me in the future. Will they actually warn the user if this happens? The npm blog post was unclear on this point: https://blog.npmjs.org/post/189618601100/binary-planting-with-the-npm-cli https://blog.npmjs.org/post/189618601100/binary-planting-wit...
inimino 7y ago
"bin": { "/usr/bin/date": "./fake-date" } The only way that can do anything scary, is if you are running `sudo npm install -g <untrusted package>`, and at that point you should already be terrified. Don't do that. This is no different from any other package you install from any third party. The author of the package is the relevant third party here, npm is just a host, they don't do your security homework for you. (Think "github", not "Debian".)

inimino 7y ago

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.

tomxor 7y ago

> What surprised me was that the "bin" names can be a relative or absolute path, like: > "bin": { "/usr/bin/date": "./fake-date" } This will only possibly work if you install it with root privileges... at which point you need to have a reasonable level of trust of the script you are running. It's unreasonable to give the same level of trust to npm packages that you do your OS package manager since anyone can publish an npm package without anyone elses permission. For this reason I think npm's defaults are a really shitty choice (global prefix under root). I always change the global prefix to live in my user directory for this reason so I can npm install -g without root: sudo npm config -g set prefix '~/.local' You will need to add the local bin to your PATH (if it doesn't already contain it) PATH="$HOME/.local/bin:$PATH" The order above is important, local must come before existing PATHs for lower precedence so that it cannot override higher privilege bins... e.g so that if an npm package added a bin for '~/.local/bin/cat', it would never be called implicitly since '/usr/bin/cat' exists.

ryukafalz 7y ago
>The order above is important, local must come before existing PATHs for lower precedence so that it cannot override higher privilege bins You've got the order reversed there - the first item found in your PATH will be used, and therefore earlier directories in your PATH have higher precedence: jfred@lambdacrypt ~$ cat dir1/pathtest #!/run/current-system/profile/bin/bash echo "script in dir1" jfred@lambdacrypt ~$ cat dir2/pathtest #!/run/current-system/profile/bin/bash echo "script in dir2" jfred@lambdacrypt ~$ PATH=$HOME/dir1:$HOME/dir2 pathtest script in dir1
- tomxor 7y ago
  You are correct my mistake.
inimino 7y ago
I don't understand the point in using ~/.local/bin and then putting it in your PATH. The point of treating /usr/local/bin and the other root-owned binary directories specially is that they are in your path, which means that if you type "ls" you want to run "ls" and not something untrusted. For that reason, anything you put in your PATH needs to be treated exactly with as much care as anything you install in /bin. The only difference might be that you don't affect other users on the same system, in a multi-user environment (which is increasingly rare). It might be convenient if you wanted to be able to clean up an entire installation by deleting one directory, but it's not a security feature. Don't install binaries anywhere in your path if you don't trust them or know where they came from. (Also, sibling is correct that first location found wins when searching PATH for a command name.) Also, it's not unreasonable to trust npm packages just like OS packages if you know who released it. NPM names are first-come, first-served, and once allocated, they are permanent. If you know and trust the person who released the package, there's nothing wrong with trusting the package. This was, in fact, the norm when npm was new and the community was small and most people knew each other. The only problem is with treating npm like a vetted distro like Debian, and assuming that anything on npm is safe to install without any connection to the author (or 1001 dependencies). That's where everything started to go sideways.

SamHasler 7y ago

> I'll be glad if npm/yarn notifies me in the future. Will they actually warn the user if this happens? The npm blog post was unclear on this point: https://blog.npmjs.org/post/189618601100/binary-planting-with-the-npm-cli https://blog.npmjs.org/post/189618601100/binary-planting-wit...

inimino 7y ago

"bin": { "/usr/bin/date": "./fake-date" } The only way that can do anything scary, is if you are running `sudo npm install -g <untrusted package>`, and at that point you should already be terrified. Don't do that. This is no different from any other package you install from any third party. The author of the package is the relevant third party here, npm is just a host, they don't do your security homework for you. (Think "github", not "Debian".)