In article <20031026130818.430969_4.rgarciasuarez@_ree._r>, Rafael Garcia-Suarez <rgarciasuarez@free.fr> writes: > I recently documented in perlsub that C<local *foo> doesn't preserve > magic on $foo, @foo, %foo etc. (perlsub/"Localization of globs"). > This feature can be useful when doing C<local *_> in order to > localize $_ _and_ drop all previous magic on $_ that might get in > the way. In other words, C<local %ENV> allows to modify the environment, > while C<local *ENV> does not. > > Considering this, I think that a glob assignment to *ENV should drop > the env magic from it, and that the core must be fixed to deal with > it gracefully. That's more consistent with the rest of perl (and the > rest of magical variables.) What I had expected to happen is that perl internally has a reference to the "real" magic env hash, and that my local *ENV = $hash_ref indeed would replace the the HASH slot in *ENV with my new reference, but that the real magic env keeps pointing to the old place. Then system/exec/qx taint checks would still be done against against this preserved "real" magic env. That would be enough to fix the security hole. The fact that it's maybe unexpected that the real env isn't changed by local *ENV=$ref, well, you can expect weird things if you write such weird code. In my particular application I don't actually want all these setenv's to happen on every little event. The only reason I set %ENV at all is to make old CGI code happy. The only time I want the real env to change in this application is when I'm indeed doing an external call, and I'm prepared to do that "by hand" if needed. -- void russian_roulette(void) { char *target; strcpy(target, "bullet"); }Thread Previous