Re: %ENV not tainted! (was Re: What tests are failing on VMS?)
At 5:04 PM -0700 9/24/01, Brad Hughes wrote:
>"Craig A. Berry" wrote:
>[...]
> > $ 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.
>
>Are both PERLSHR.EXEs on the same machine? And if so, might
>one be INSTALLed with privs?
Interesting thought, but no, nothing's installed as a known image.
I've also reproduced the same behavior on a different machine.
--
Craig A. Berry
mailto:[EMAIL PROTECTED]
"Literary critics usually know what they're
talking about. Even if they're wrong."
-- Perl creator Larry Wall
Re: %ENV not tainted! (was Re: What tests are failing on VMS?)
"Craig A. Berry" wrote:
[...]
> $ 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.
Are both PERLSHR.EXEs on the same machine? And if so, might
one be INSTALLed with privs?
Brad
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 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. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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 L:
At present, the first time you iterate over %ENV using
C, or C, 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.
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
Re: %ENV not tainted! (was Re: What tests are failing on VMS?)
On Sun, Sep 23, 2001 at 02:39:32AM -0400, 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?
This adds an explicit test to make sure %ENV is tainted. It will
fail.
--- t/op/taint.t2001/09/23 06:30:06 1.1
+++ t/op/taint.t2001/09/23 06:49:07
@@ -109,7 +109,7 @@
close PROG;
my $echo = "$Invoke_Perl $ECHO";
-print "1..175\n";
+print "1..176\n";
# First, let's make sure that Perl is checking the dangerous
# environment variables. Maybe they aren't set yet, so we'll
@@ -825,7 +825,8 @@
use warnings;
-$SIG{__WARN__} = sub { print "not " };
+my $saw_warn = 0;
+$SIG{__WARN__} = sub { $saw_warn++ };
sub fmi {
my $divnum = shift()/1;
@@ -836,7 +837,7 @@
fmi(37);
fmi(248);
-print "ok 174\n";
+print !$saw_warn ? "ok 175\n" : "not ok 175\n"
}
@@ -871,4 +872,5 @@
}
-
+my $env_val = (values %ENV)[0];
+print tainted($env_val) ? "ok 176\n" : "not ok 176\n";
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Maybe they hooked you up with one of those ass-making magazines.
-- brian d. foy as misheard by Michael G Schwern
