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.

3
  • 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 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 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 at 14:56

1 Answer 1

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
1
  • 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 at 15:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.