Front page | perl.perl5.porters |
Postings from October 2003
hv@crypt.org wrote:
> Ouch. I note that also if the new %ENV includes a PATH I get a
> coredump instead:
>
> perl -Twe '%a=(PATH=>"util"); *ENV=\%a; system("echo unsafe")'
> Segmentation fault (core dumped)
> zen%
> #0 Perl_mg_find (sv=0x814dee0, type=101) at mg.c:327
> #1 0x081129f3 in Perl_taint_env () at taint.c:116
> #2 0x080f96a7 in Perl_pp_system () at pp_sys.c:4076
> [..]
>
> I believe this is happening because mg_find() assumes it will never
> be called with an SV that isn't magical, and taint_env() assumes
> that anything pulled out of %ENV will always have magic attached.
That's correct, and I fixed the coredump case by change #21542.
$ENV{PATH} is still checked for taintedness when %ENV is aliased to
another hash, although this might be a bit futile in this situation.
> The main question I think is what C< *ENV = \%myenv > should mean:
> either it should act to replace the environment or not, and the
> rest of the core should act appropriately either way. I think in
> principle it would be most useful for it to replace the environment,
> but I accept that that involves a lot of extra code and could also
> make C< *ENV = \%myenv > unexpectedly slow. This implies that eg
> C< local %ENV = ( PATH => $path ) > should also work.
>
> (Hmm, can we even tell? C< *ENV = \*A; *A = \%myenv > may make
> things tricky.)
Maybe do nothing and let people shoot in their feet.
Maybe just forbid aliasing *ENV at all. (with the collateral damage
on $ENV etc.) (or couldn't this chained alias thing be solved
by looking at the GvEGV ?)
Thread Previous
|
Thread Next