The last 2 tests in utftaint.t are failing on VMS.

Insecure $ENV{PATH} while running with -T switch at ./test.pl line 547.

I am a bit stumped on how to fix this.

Traditionally on VMS, PATH does not exist.

The C library on VMS helps out and creates a PATH environment variable when it is referenced. And this appears to be considered tainted by Perl.

Apparently when Perl runs anything in a subprocess, it references this $ENV{PATH}, as when I run the test program from the CLI, it runs just fine.

Attempting to untaint this $ENV{PATH} causes a LOGICAL NAME PATH to exist and it still appears to be tainted, and I am not sure how to fix this if this is the problem.

Changing ENV{PATH} results in a logical name PATH existing after perl exits which may affect other programs. Even setting the logical name PERL_ENV_TABLES to CRTL_ENV does not fix this issue.

Interestingly enough, it does not appear easy for Perl on VMS to detect if a PATH logical name existed before it was run and modified, so Perl can not clean up.

setting $ENV{PATH} = "" results in a logical name PATH created with a single character value that is persistent when Perl exits.

It also seems to be one of the ways to untaint PATH.

using delete $ENV{PATH} also results in PATH being untainted, and does not leave a logical name behind.

This only works if a PATH logical name did not exist before delete $ENV{PATH} was called. Because then delete $ENV{PATH} just removes the logical name PATH and that leaves C library generated PATH existing.

In that case two delete $ENV{PATH} calls are needed.

Now if there was a DCL symbol path, then it is probable that it will be tainted also, so to be sure three delete $ENV{PATH} calls would be needed.

This is an artifact of the way environment variables are implemented in Perl and the C library.

In the C library, if the environment variable does not exist, then it looks in the DCL symbol table, and finally all the logical name tables in the project path, and if it is still not resolved and it is one of a few special ones, including PATH, the C library generates it. Modified environment variables are put in the C library environment table.

In Perl on VMS by default, it follows close to the above, except that modified $ENV{} are put in the process logical name table.

So should test.pl on VMS be doing a delete $ENV{PATH} three times to make sure it untainted as a fix?

Or should something be done inside of VMS perl to figure out how to untaint an $ENV{} value.

-John
[EMAIL PROTECTED]
Personal Opinion Only

Reply via email to