In the process of cleaning up the static build, I've come across an annoying
problem with open_cmd() it clears the PATH for taint-safety.
The problem with this is when httpd is the libtool generated wrapper in the
httpd source tree. That shell script needs rm, ls, echo, etc and fails miserably
when there is no PATH set.
This suggested path simply untaints the PATH instead of clearing it.
I am not sure what security is lost by this change, so I'd like to hear if anybody
can think of a good reason why this would be a bad idea ?
I think it makes sense. Perhaps documenting that nuance is the best solution. Folks wanting to clean up their path can do so in t/TEST.
But it has to be like so:
sub open_cmd {
my($self, $cmd) = @_;
# untaint some %ENV fields
local @ENV{ qw(IFS CDPATH ENV BASH_ENV) }; # Temporarly untaint PATH
(local $ENV{PATH}) = ( $ENV{PATH} =~ /(.*)/ );
# -T doesn't like . in the PATH
$ENV{PATH} =~ s#(^|:)\.[/\\]?(:|$)##;since if you have "." in the path, perl dies with:
% perl -Tle '$ENV{PATH} = "."; qx[echo doh]'
Insecure directory in $ENV{PATH} while running with -T switch at -e line 1.we could even add a warning to say that "." was removed. But it probably makes no sense, since so far we were silently wiping it off completely.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
