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
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:
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.
[jbecker@deadlands /]$ echo $CDPATH
[jbecker@deadlands /]$ pwd
[jbecker@deadlands /]$ file /home/jbecker/pilot
[jbecker@deadlands /]$ cd pilot
[jbecker@deadlands pilot]$ pwd
- $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
- $BASH_ENV: from the bash man page:
It's the same, essentially, as ENV. Icky.
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.