This sounds very weird.
I note that . was reomoved from @INC in Perl 5.26, but this has nothing to do with taint mode. It would describe the symptoms you describe without needing to involve mythical ideas about how taint mode could work or how taint mode could always be enabled though.
Maybe simply putting . into @INC already solves your problem? Setting PERL_USE_UNSAFE_INC could be a band-aid for that issue. Also consider the code mentioned in the perldelta:
BEGIN {
my $dir = "/some/trusted/directory";
chdir $dir or die "Can't chdir to $dir: $!\n";
# safe now
push @INC, '.';
}
use "Foo::Bar"; # may load /some/trusted/directory/Foo/Bar.pm
do "config.pl"; # may load /some/trusted/directory/config.pl
See perl5260delta.pod | [reply]
[d/l]
[select] |
Corion,
I dealt with this one awhile back. The discovery turned out to be that it is not possible to disable taint-checks on the path (@INC) post version 5.26; however, it is possible to appease taint, simply by setting the path. This is a step that was not required in earlier versions, but which is no longer optional as a result of taint. So while some may claim taint is not in use if not invoked, this is simply not the whole truth.
See more on that here: Proper and acceptable use of backticks in a modern Perl script.
| [reply] |
Try not enabling taint in some post-5.26 version of Perl and then discovering that your path in that backticks command was tainted, preventing your script from running.
Sure, let's try that:
$ perl -E 'say $^V; say qq/Taint mode: ${^TAINT}/; say qx/date/'
v5.34.0
Taint mode: 0
Thu 26 Oct 09:57:36 BST 2023
$
Taint mode is entirely unsurprisingly not enabled and the code inside qx// runs just fine.
| [reply]
[d/l]
[select] |
Like hippo showed, my experience disagrees completely (*).
Here's an example of taint vs non-taint with Strawberry 5.32, where I am running 'notepad++.exe', which is in my path.
C:> perl -TE "say $^V; say qq/Taint mode: ${^TAINT}/; system(qq/notepa
+d++.exe --help/)"
v5.32.1
Taint mode: 1
Insecure $ENV{PATH} while running with -T switch at -e line 1.
C:> perl -E "say $^V; say qq/Taint mode: ${^TAINT}/; system(qq/notepad
+++.exe --help/)"
v5.32.1
Taint mode: 0
The first time, I force taint mode, to show the message when taint is active. The second time, I run it again without forcing taint mode, and it shows that it runs without giving me the insecure-path message. This plainly shows that it's not automatically forcing taint mode just because the version of perl is above 5.26.
In the other topic you mentioned, you said you were in a 'use CGI' environment. Depending on how your webserver is set up, your real and effective user and/or group ids may be different, which would trigger automatic taint mode, as corion said much earlier in this conversation. My webserver does not, as I just checked by running: print "Real Group: $(\n";
print "Effective Group: $)\n";
print "Real User: $<\n";
print "Effective User: $>\n";
print "Taint? ${^TAINT}\n";
inside a script. If I run normally, the last line prints 'Taint? 0' , whereas if I add -T to the shebang in my CGI script, that last line prints 'Taint? 1' , so I know that it can properly identify taint mode.
So you should use the '${^TAINT}' to verify that you really are in taint mode. And use the real/effective group and user id variables to confirm what those are set at, to see if one of those is your culprit.
Also, you have not shown us a Short, Self-Contained, Correct Example which replicates your tainted results when you don't think you should be in taint, showing that code without taint errors in pre-5.26 will show a taint error in post-5.26, without you intentionally enabling taint mode. Can you share such an SSCCE?
*: Well, almost like hippo. I could not get taint mode to complain when I force taint mode and used 'qx' or backticks, like C:> perl -TE "use warnings; use strict; say $^V; say qq/Taint mode: ${
+^TAINT}/; qx/notepad++.exe --help/"
v5.32.1
Taint mode: 1
... which is why I switched to 'system' instead. So it may be that hippo's qx experiment wasn't sufficient, though I don't expect the non-forced-taint-mode results to change, even if hippo changes over to 'system' instead of 'qx' .
edit: clarified/reworded footnote | [reply]
[d/l]
[select] |
$ perl -TE 'say $^V; say qq/Taint mode: ${^TAINT}/; say qx/date/'
v5.34.0
Taint mode: 1
Insecure $ENV{PATH} while running with -T switch at -e line 1.
$
Similarly the results using system are also as expected:
$ perl -E 'say $^V; say qq/Taint mode: ${^TAINT}/; system q/date/'
v5.34.0
Taint mode: 0
Thu 26 Oct 17:07:03 BST 2023
$ perl -TE 'say $^V; say qq/Taint mode: ${^TAINT}/; system q/date/'
v5.34.0
Taint mode: 1
Insecure $ENV{PATH} while running with -T switch at -e line 1.
$
In case it is unclear, I am running these on a non-MSWin32 system.
| [reply]
[d/l]
[select] |
Interesting.
Just in case it was something to do with version, and now that Strawberry has something newer than 5.32: I downloaded Strawberry 5.36, and tried again, comparing qx vs system for the same command.
C:> perl -TE "say $^V; say qq/Taint mode: ${^TAINT}/; say qx/date/;"
v5.38.0
Taint mode: 1
Thu Oct 26 09:43:51 Pacific Daylight Time 2023
C:> perl -TE "say $^V; say qq/Taint mode: ${^TAINT}/; say system(qq/da
+te/);"
v5.38.0
Taint mode: 1
Insecure $ENV{PATH} while running with -T switch at -e line 1.
So apparently the Strawberry build on MSWin32 doesn't do taint checking on qx but it does on system. I'm now curious whether syphilis or someone else who has their own build(s) of MSWin32 perl.exe could check on one or more of 5.32, 5.34, and 5.38, to see if there's something about Strawberry's build, or something about MSWin32 builds in general, which cause tainting to behave differently. | [reply]
[d/l]
[select] |