Re: %ENV not tainted! (was Re: What tests are failing on VMS?)
At 11:59 AM 9/24/2001 -0400, Dan Sugalski wrote:
At 11:23 PM 9/23/2001 -0500, Craig A. Berry wrote:
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.
I think the ultimate issue is that %ENV elements fetched from trusted
sources (Like the SYSTEM or CLUSTER mode logicals) are considered untainted,
while the process-level stuff is tainted. Seemed that way the last time I
dove through the twisty mazes, but I might've misread things.
Well, my previous theory is full of it since there is code in hv.c to taint
keys and values retrieved from the pre-loaded %ENV hash. Here's an example
from hv_fetch():
#ifdef DYNAMIC_ENV_FETCH /* %ENV lookup? If so, try to fetch the value now */
if (SvRMAGICAL((SV*)hv) mg_find((SV*)hv, PERL_MAGIC_env)) {
unsigned long len;
char *env = PerlEnv_ENVgetenv_len(key,len);
if (env) {
sv = newSVpvn(env,len);
SvTAINTED_on(sv);
if (key != keysave)
Safefree(key);
return hv_store(hv,key,klen,sv,hash);
}
}
#endif
I think Dan may be onto something though. It seems that not any arbitrary
element of the keys or values of %ENV is guaranteed to be tainted since some
of them are and some of them aren't, and that's by design. However, this
does not mean all is well. On the same system with the same environment, I
see this with Perl 5.5.3:
$ perl -Twle my $foo = (values %ENV)[-1]; 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
but with 5.6.1 there is no taint warning running the identical code. Sigh.
More dredging in the code and the archives to figure out how this is
supposed to work and what got broken.
Re: %ENV not tainted! (was Re: What tests are failing on VMS?)
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 Lperlvms/%ENV:
excerpt
At present, the first time you iterate over %ENV using
Ckeys, or Cvalues, 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
%ENV not tainted! (was Re: What tests are failing on VMS?)
On Sat, Sep 22, 2001 at 10:59:34PM -0500, Craig A. Berry wrote:
Ok, taint.t. The problem is either inside tainted() or a problem with
how it's picking it's value. I don't think the problem is that %ENV
is not tainted.
Maybe, maybe not. There is a good deal of special handling of both
%ENV and tainting in vms/vms.c. We could have a genuine bug there,
or it may just be test bugs. I'll post the taint test failures in a
separate message.
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?
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
That which stirs me, stirs everything.
-- Squonk Opera, Spoon
