At 2:39 AM -0400 9/23/01, Michael G Schwern wrote:
>
>I just ran the taint tests. It looks like VMS's %ENV is *not* tainted.
>
>$ perl -"Twle" "my $foo = (values %ENV)[0]; open(FILE, qq{>$foo})"
>Name "main::FILE" used only once: possible typo at -e line 1.
>
>Whereas on Unix that would cause a taint error.
>
>I know environment variables are a bit different on VMS than Unix. Is
>there any reason you wouldn't want %ENV to be tainted?
Hmm. Generally the environment does taint. For example:
$ DEFINE FOO BAR
$ perl -"Twle" "my $foo=$ENV{'FOO'}; open(FILE, qq{>$foo})"
Name "main::FILE" used only once: possible typo at -e line 1.
Insecure dependency in open while running with -T switch at -e line 1.
%SYSTEM-F-ABORT, abort
I don't quite know how to prove this yet, but I think the reason the
example with "values %ENV" doesn't work derives from the following
behavior as described in L<perlvms/%ENV>:
<excerpt>
At present, the first time you iterate over %ENV using
C<keys>, or C<values>, you will incur a time penalty as all
logical names are read, in order to fully populate %ENV.
Subsequent iterations will not reread logical names, so they
won't be as slow, but they also won't reflect any changes
to logical name tables caused by other programs.
</excerpt>
Basically we're pre-loading a hash when you use "keys" or "values" on
%ENV, and if I understand this right, hash elements are not
full-blown scalars and thus do not have tainting bits. Getting an
individual element from %ENV, on the other hand, never involves a
real hash since we just call getenv() or moral equivalent and return
a single (tainted) scalar value. The code where this is implemented
in vms/vms.c is pretty twisty stuff and I don't quite have a good
enough grasp of it yet to be sure this is right or know what to do
about it.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
