Why does Perl not want to require certain files when running under -T?

Question

I recently noticed that on my system it is not possible to require 'lib/file.pl' when running under -T, but require './lib/file.pl' works.

$ perl -wT -e 'require "lib/file.pl";'
Can't locate lib/file.pl in @INC (@INC contains: /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.14.2 /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/5.14.2 /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/site_perl)

$ perl -wT -e 'require "lib/file.pl"'

Doing it without -T works in both ways: $ perl -w -e 'require "lib/file.pl"' $ perl -w -e 'require "./lib/file.pl"'

In taint mode, . is not part of @INC.

perl -w -e 'print "@INC"'
[..snip..] /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/site_perl .
perl -wT -e 'print "@INC"'
[..snip..] /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/site_perl

I could not find that behavior in the doc. Can someone please tell me where this is documented or why -T doesn't like . as a lib directory?

Answer 1

Erm... this is actually well documented, I suppose:

When the taint mode (-T ) is in effect, the "." directory is removed from @INC , and the environment variables PERL5LIB and PERLLIB are ignored by Perl. You can still adjust @INC from outside the program by using the -I command line option as explained in perlrun.

... but that's only a half on an answer, I suppose. The reasons behind such decision are given here:

... the issue with @INC is really more of a problem with SUID scripts than CGI scripts. When you have an SUID script that can execute with the permissions of another user (such as root), Perl goes into taintmode automatically.

For this SUID script case, it would be a huge security breach to have the capability of loading libraries from the user's current directory. If a script ends up having a bug where the library is not found in the normal directory path, then a user could exploit this by writing their own, malicious version of the library, putting it in the current directory, and running the SUID script from their current directory.

However, this is not really the same problem with CGI scripts. User's are not executing your script from arbitrary directories. Your web server controls which directory the script is called from. So keeping "." in @INC is not really a problem compared to SUID scripts which operate under taint mode automatically.