On 19 Apr 2017, at 9:52, Robert Steinmetz wrote:
Robert Steinmetz wrote:
Responding to my own post with new information.
I think I've confirmed that the problem is the $PATH, or the perl
equivalent.
I added the full path name where the specific commands were called and
that removed that error. Some of the commands seem to be called from
other perl scrips so the problem seems to be my perl set up.
But I'm not clear how perl actually sets the path.
Inside a perl script, the execution environment is available in the %ENV
hash, with variable names as keys, so the execution search path "PATH"
is "$ENV{'PATH'}". The %ENV hash is considered "tainted" as
untrustworthy input by perl, so if the interpreter is run with the "-T"
option, any subprocess launched by perl won't get any environment
variables unless the script has done something to "untaint" members of
that hash. The sa-compile script DOES use a SA utility function to
untaint the whole %ENV hash, but there's a special catch for
$ENV{'PATH'}: if any directories included are not absolute (e.g.
commonly '.' and '~/bin') OR are writable by more than their owning user
& group, $ENV{'PATH'} remains tainted and won't be used or passed to
child processes. Often a bad member directory is unobvious because it is
a symlink name and symlinks are usually technically mode 777 because the
system doesn't use the mode of a symlink itself.
What I expect is happening is that there's a problematic directory in
the $PATH that perl gets when executed, so the blind untainting of
$ENV{'PATH'} that sa-compile does won't work. The best fix is to find
the insecure member of $PATH and remove it before trying to run
sa-compile.
