Adding ./bin to your PATH is a bad practice

[corasaurus-hex]

On the wiki page on plugins under the section Bundler integration, it is recommended to stay away from the rbenv-bundler plugin and instead use bundler's binstubs. What concerns me is that it also encourages users to put ./bin in their PATH. This is not much better than having . in your path.

http://www.faqs.org/faqs/unix-faq/faq/part2/section-13.html

[corasaurus-hex]

The page on understanding binstubs also encourages this practice at the end of the section titled Bundler-generated binstubs.

[jeremy]

It does pose a concern in production or when you're sharing a development machine with untrusted users and /tmp isn't mounted noexec. These are not recommended for a relative ./bin.

For personal dev machines, home to a single user, doing away with the leading ./bin is a sweet win.

Updated the wiki to clarify. Thanks @nate!

[corasaurus-hex]

Thanks for fixing this, although I'm not sure we're exactly on the same page, or maybe I just don't follow. Even on personal dev machines it's risky to use relative paths in PATH. It may be that it's better explained with an example.

Suppose for a moment that PATH has ./bin in it. You're investigating a new piece of software you found that doesn't have a tremendous amount of information about it online, but it does allow you to download tarballs. Or maybe you don't see that there's a bin directory and you check out the source code. Either way, you have an untrusted source directory that you're investigating.

curl http://example.com/path/to/package.tar.gz
tar zxf package.tar.gz
cd package

Now suppose that the package directory has a bin directory within it. Since ./bin was prepended to PATH, this untrusted package's binaries now can be accidentally run if they overlap with anything you else you have on your system, or if you typo. If bin has ls in it, or sl, or cat, or anything that you might run, you may accidentally run a command you hadn't intended.

This is one of the major reasons why . is not in the PATH for bash and why . is not in $: for Ruby (anymore). It's risky to use any path that doesn't start with / in your PATH.

[mislav]

@nate: we understand. However I usually don't download and untar projects that want to hack my system. Not terribly concerned about that.

In the guide, I only suggested putting ./bin in your PATH. That can be just for that project (i.e. that shell session), not permanently in your bashrc. It's up to people to choose the line between convenience and security.

[corasaurus-hex]

Even if we set aside deliberate hacking, and I don't think that's a good idea, this still leaves the system open for accidental overrides of commands, even with important, basic POSIX commands. There is still substantial risk there, risk that the wider community has deemed too much to tolerate (see '.'). I don't think it sounds like a suggestion in the wiki, and even if it was it sets a bad precedent. This is a major project, a respected project, built by people who are respected in the community, and it's recommending a relatively dangerous practice. Those who aren't acutely aware of the risks will be led to believe this is ok.

I feel like this isn't going anywhere so I won't push it anymore, but just please consider your position and the risk involved.

[nihilismus]

What about rbenv-vars plugin?, you could have something like:

PATH=$PATH:$PWD/bin

inside a .rbenv-vars file (in your project) and then execute eval $(rbenv vars) to update the $PATH in your current shell/terminal w/o the need of ./bin in your global $PATH.

[corasaurus-hex]

That's a bit of an improvement, but I think they're trying to avoid having to type anything extra to have the correct gem loaded. I think the best way to do this and avoid having ./bin in your global PATH is to do it at the gem shim level and have trusted directories. Automation of the trusting of directories would make it trivial from a user's perspective, you'd only have to approve it once per project (a la .rvmrc with RVM).

[nihilismus]

@nate: well, as far as i know with rbenv There's nothing to "trust." so no magic-automation would be added to "fix" this, but JMHO.

BTW, it should be:

PATH=$PWD/bin:$PATH

[corasaurus-hex]

With rbenv-vars, there is a project specific .rbenv-vars file. If we're being concerned about accidentally running things from ./bin, then autoloading .rbenv-vars which changes the path could be just as problematic. Am I missing something here?

[nihilismus]

@nate: with rbenv-vars you would get a new value in PATH but not with ./bin (relative path) but with the full path to ./bin. Let's say you are at /path/to/project, then with my instructions you would get a PATH like /path/to/project/bin:~/.rbenv/shims:~/.rbenv/bin. There is no more relative path in your PATH (as suggested in the wiki) and i think this address your concern.

[corasaurus-hex]

My whole argument is based around explicitly granting trust, in this case to directories. Defaulting to trusting nothing and explicitly granting trust is a security posture known as default deny. rbenv-vars seems to implicitly trust any .rbenv-vars file, and these files can modify your path. Is that correct? If so, you could just as easily run a file you hadn't intended to because a .rbenv-vars could modify PATH to point somewhere you didn't want it to, and at runtime so you can't even back out of it before it's already running. If this is the case, then this is just as bad as putting ./bin in your PATH.

[jeremy]

@nate Agreed. Letting the current working dir alter your env is great for the 99% case but can really burn in the 1% case. Setting PATH in .rbenv-vars along with a whitelist of safe dirs would be a good way forward, but I'm not sure whether that'll work. Depends on when the file is loaded.

Check out zimbatm/direnv#23 for similar considerations with direnv's .envrc file.

Volunteers welcome to help flesh out the Right Way to do convenient app executables in dev without compromising security (or unexpectedly stubbing your toes).

[corasaurus-hex]

I'll move this over to to the rbenv-vars project then and see if anyone wants to chime in. I'd love to help out but I'd like to get feedback on my idea (or outright rejection of it) before I start in on it, if for no other reason than I'm not the world's greatest shell programmer. Thanks for all the feedback, everyone.

[mislav]

rbenv's philosophy is to avoid shell hacks such as hooking into cd or prompt to set the right Ruby version. However, hooking into cd seems like it might be a good solution for the problem at hand (which doesn't have anything to do with rbenv, mind you).

What I consider to be safe behavior: when you change into a directory that has a bin dir, shell hook checks if that directory is whitelisted. If it is, then prepends it to the PATH. When you change to another directory, the previous bindir is stripped from PATH.

My implementation (zsh only):

if [[ -n $ZSH_VERSION ]]; then
  [[ -z $AUTOBIN_LIST ]] && AUTOBIN_LIST=~/.config/autobin

  _autobin_hook() {
    if [[ -n $AUTOBIN_DIR ]]; then
      # remove old dir from path
      path=(${path:#$AUTOBIN_DIR})
      unset AUTOBIN_DIR
    fi
    if [[ -d "${PWD}/bin" ]] && grep "${PWD}/bin" "$AUTOBIN_LIST" >/dev/null 2>&1; then
      # add whitelisted dir to path
      AUTOBIN_DIR="${PWD}/bin"
      path=($AUTOBIN_DIR $path)
    fi
  }

  [[ -z $chpwd_functions ]] && chpwd_functions=()
  chpwd_functions=($chpwd_functions _autobin_hook)
fi

[nihilismus]

@nate: could you please give a concrete example-situation so i can be on the same page? Maybe we could get a more reasoned solution if actually there is a security problem.

"If so, you could just as easily run a file you hadn't intended to because a .rbenv-vars could modify PATH to point somewhere you didn't want it to."

A .rbenv-vars is going to modify your PATH because that what you want. You are explicitly asking for that if you follow my instructions. If you do not know why and with what you are modifying your PATH then i think there is a PEBKAC.

@mislav: with your suggestion i think all you are going to get is a "false sense of security". The problem is not in trusting directories but trusting their content.. If there is a ruby shell script inside /path/to/project/bin that does rm -f ~ you would be in troubles in anyway. Yeah, now you are asking to yourself "why and how a ruby that deletes my ~ is inside my /path/to/project/bin?"... something similar i asked to myself when @nate said: ".rbenv-vars could modify PATH to point somewhere you didn't want it to".

Anyway, remember KISS.

[mislav]

I don't think whitelisting project directories on my machine is a false sense of security. By whitelisting a directory, I'm making myself aware that this bin/ directory is now going to be in PATH, and that I should not extract anything suspicious in here or letting someone else other than me have write access. And yes, I trust the content of my own projects that I'm working on.

This approach should be as secure as putting any other system dir in my PATH via ~/.zshrc.

[corasaurus-hex]

@nihilismus: I don't know about you, but I download a lot of projects to check them out. If they happen to have a .rbenv-vars file that adds ./bin to PATH, or if I have ./bin in my PATH already, then whatever they have in ./bin will override my normal, curated PATH that contains directories that I consider sufficiently safe. As for what you addressed to @mislav, you're right that you must trust the binaries in the directory, not necessarily the directory. Unfortunately, this is too much labor to be practical. Instead we choose directories that we are going to trust as a proxy for that and call it good enough.

Regarding trusting directories, this is how I would like to see this work, more or less.

Suppose that this is how directories and .rbenv-vars files are trusted:

filemd5=$(cat .rbenv-vars | md5)
pathmd5=$(echo `pwd` | md5)
trusted=true

mkdir -p "~/.rbenv-vars/trusted_paths/$pathmd5"
echo $trusted > "~/.rbenv-vars/trusted_paths/$pathmd5/$filemd5"

A trust check might look like:

filemd5=$(cat .rbenv-vars | md5)
pathmd5=$(echo `pwd` | md5)

if [ -f "~/.rbenv-vars/trusted_paths/$pathmd5/$filemd5" && `cat ~/.rbenv-vars/trusted_paths/$pathmd5/$filemd5` == "true" ]; then
   # load .rbenv-vars file
else
    echo "Untrusted file found, do you want to trust this file?"
    read trusted
    if [ $trusted == "true" ]; then
      # do the code to store that this file is trusted
      # load .rbenv-vars file
    else
      echo "k then, later"
      exit 1
    fi
fi

With this you could confirm at runtime whether a file is trusted or not and it should offer much better security. The bonus is that you only have to confirm trust on changes and in new projects, so it's low burden.

Thoughts?

[mislav]

@nate: It's an interesting approach. However, I wouldn't want to be nagged with "do you want to trust this file?" for every change made to .rbenv-vars. For me (and I presume many other people) trust works like this: when I check out a project and see its source and decide I want to work on it/use it, I start to trust that it's non-malicious and that future updates will be non-malicious. My trust spans for the lifetime of my involvement in the project. So these nag messages would not provide value for me; they would just be inconvenient.

[corasaurus-hex]

I can definitely see the value in just trusting the project altogether. For most projects this is probably fine. How often do .rbenv-vars files tend to change for you? Often?

As with most security concerns it's a matter of balancing risk with convenience. I can see three issues with trusting directories, and they're possibly non-issues:

1. Re-using paths. If you re-use paths, this would automatically trust a different project. On the other hand, it's entirely possible that this new project would have the same .rbenv-vars file (think export PATH=./bin:$PATH) and that would be trusted when you wouldn't want it to be even if you were hashing the files. There's not really a good way solve this. And anyways, it's rare in my experience to re-use paths, so this is probably not something worth protecting against.
2. Changes in .rbenv-vars that probably shouldn't have been made. Accidents happen, junior developers make changes that should have been local to their own machine, smaller projects maintainers makes personal-dev-machine-specific changes to their project, etc. This is probably low risk as well.
3. The nag of file changes notifies you that running commands will result in different behavior. Without the nag you might waste time debugging a non-issue that resulted from environment variable changes. This, too, may be a minor issue.

So, anyways, I think this hinges on how often .rbenv-vars changes. If it rarely changes, then hashing the file offers greater security, and notifies you of changes in behavior, with very little cost. If .rbenv-vars changes quite a bit (even when changing branches), then hashing the file is annoying and unnecessary.

I would be fine with either way of doing things.