fnm icon indicating copy to clipboard operation
fnm copied to clipboard

Option to append the PATH?

Open chocolateboy opened this issue 5 years ago • 4 comments

OS: Linux (Arch) | fnm: v1.22.8

The output of fnm env on my system (Bash v5.0.18) prepends its bin directory to the $PATH, e.g.:

export PATH="/tmp/fnm_multishell_123_456/bin":$PATH

I know this is useful for some users who want to pre-empt their system node binary, but it also puts binaries bundled by global node modules at the front of the path, ahead of ls, /usr/local/bin etc., which I'd rather not risk. It's not just compromised or malicious packages I'm concerned about. Different operating systems and distros have different packaged binaries, so it's easy to accidentally (or deliberately) choose a name that's a privileged command on someone's system.

I'm working around this at the moment by post-processing the output of fnm env to move its path to the end before evaling it, but it would be great if this could be done automatically, perhaps via an option, e.g. fnm env -a or fnm env --append.

chocolateboy avatar Dec 06 '20 15:12 chocolateboy

see the suggestion/workaround here: https://github.com/Schniz/fnm/issues/163#issuecomment-549496176

edit: ignore this, looks like you're already doing this

acx0 avatar Dec 21 '20 00:12 acx0

but it also puts binaries bundled by global node modules at the front of the path, ahead of ls, /usr/local/bin etc., which I'd rather not risk

I have never thought about it. You're right. That can be a security issues. That being said, appending can cause issues if let's say you have a system installation of Node in /usr/local/bin or /bin — and tools like Cargo, OPAM, rbenv etc all prepend. So I'm not sure that appending might be the solution.

Do you think there's a better solution for that? That will also be risk-free and without these drawbacks?

Schniz avatar Dec 21 '20 07:12 Schniz

Also, thanks for opening the issue. Very informative. And sorry for my delay.

Schniz avatar Dec 21 '20 07:12 Schniz

That being said, appending can cause issues if let's say you have a system installation of Node in /usr/local/bin or /bin

Right. That's why I think it should be an option (e.g. fnm env --append), rather than the default.

tools like Cargo, OPAM, rbenv etc all prepend

Yes, many tools do it for convenience, despite the security concerns (which makes me wonder if there are systems which are unwittingly using a version of ls written in Rust or JavaScript).

Usually I just scrub the PATH from the output and set it manually, e.g.:

eval $(foo env | grep -v '\bPATH=')

export PATH="$PATH:$HOME/.foo/bin"

But fnm's PATH isn't static and my command for rewriting it became so complex (and fragile) that I figured it'd be easier to ask for an official solution :-)

Do you think there's a better solution for that? That will also be risk-free and without these drawbacks?

I'm not aware of any issues if appending is optional.

chocolateboy avatar Dec 21 '20 10:12 chocolateboy