0

Say I want to do source $VIRTUAL_ENV/bin/activate in my bashrc whenever the VIRTUAL_ENV is defined.

In general, the idea of running a script pointed by an environment variable seems a bit fishy as it can by writable by other users. So it would seem a check of permissions is desirable, in a fashion similar to the .ssh/config. Is that the common practice?

On the other hand, the VIRTUAL_ENV goes into PATH anyway, so if anyone managed to tamper with that directory, you're screwed anyway, why bother. Or rather than give up you can go deeper and ensure that any directory added to PATH is writable by root+yourself only.

So what are the good practices on what to trust and not to trust regarding the process environment? I'm somewhat surprised shells don't already validate the permissions on directories that're added to PATH.

salmin
  • 103
  • 1
  • You're better off parsing the file with your own code rather than letting it execute arbitrary code of its own. If you're adding to the path, you'll need to ensure the item is added to the _end_ of the path and is not itself relative (or empty, which is the same as `.`). Permissions aren't an issue (shells ignore $PATH entries they can't read). – Adam Katz Sep 19 '22 at 17:55
  • @adam-katz "shells ignore $PATH entries they can't read" -- that's not the issue. A directory in the PATH **writable** by another user is a security hole. – salmin Sep 20 '22 at 12:14
  • Yes, that's why you must add paths to the _end_, so an attacker can't drop in a replacement script for some essential tool. Then at least you're only risking the items that live in the writable location. Better still: allow the user to specify a drop-box directory instead and then set up a review system before propagating its contents into the path. – Adam Katz Sep 20 '22 at 14:56

1 Answers1

1

Environment variables aren't writable by another user, because they are a process variable, not an user variable. So bash have its own variables (set on .profile, .bashrc et al), but every instance of bash can have its own sets of variables by using set, unset, export...

If you create scripts that aren't readable nor writable by other users, it's fine. You can create a file with the needed variables (e.g. $HOME/myVarsFile) and source it from your script.

If you want to check the file permissions before sourcing it, you can use stat:

PERMS=`stat -c "%a" ~/myVarsFile`
if [ $PERMS != "600" ] ; then
  echo Invalid permissions on myVarsFile
  exit 1
fi
source ~/myVarsFile
ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • 1
    Warning, `stat -c %a FILE` only works with GNU Coreutils (Linux). Mac/BSD would use `stat -f %p FILE` and note that its output is slightly different (`%p` is "type and permissions", e.g. `40755` for a directory), so maybe use `PERMS=$(stat -c %a ~/myVarsFile 2>/dev/null || stat -f %p ~/myVarsFile |grep -o '...$')` instead. – Adam Katz Sep 20 '22 at 15:02