They all deal with shells, and executing external commands.
If you are 100% sure that you do not execute
any
external commands at all, then you don't need to worry
about them. This means that your code can't have any
system or
exec,
but you should also be wary of
open, and (I think)
syscall.
- $IFS is the "Internal Field Seperator" used between
fields on a command line. For example, if you set IFS="/",
then /usr/bin/ls becomes "usr bin ls". This happens before
the shell looks for the command in the path, so if someone can
place a command called "usr" in the path, that will be executed
instead of what you intended.
- CDPATH is to the 'cd' command as $PATH
is to executing a command. An example:
[jbecker@deadlands /]$ echo $CDPATH
/home/jbecker
[jbecker@deadlands /]$ pwd
/
[jbecker@deadlands /]$ file /home/jbecker/pilot
/home/jbecker/pilot/: directory
[jbecker@deadlands /]$ cd pilot
/home/jbecker/pilot
[jbecker@deadlands pilot]$ pwd
/home/jbecker/pilot
This could be bad if you use relative directories within your
code and execute things within them. I expect this is more
of a shell programming issue, but it can bite you with perl as well.
- $ENV usually is the full path to a file that
gets executed by certain shells (MKS Korn shell at least)
before it (the shell) does anything else. This could easily
be used to create a setuid root shell if something is tricked
into running a shell as root that, in turn, executes the $ENV
file.
- $BASH_ENV: from the bash man page:
When bash is started non-interactively, to run a shell script,
+for example, it looks
for the variable BASH_ENV in the environment, expands its value
+ if it appears there,
and uses the expanded value as the name of a file to read and e
+xecute. Bash behaves
as if the following command were executed:
if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
but the value of the PATH variable is not used to search for th
+e file name.
It's the same, essentially, as ENV. Icky.
