Почему Perl не хочет требовать определенных файлов при запуске под -T?

Я недавно заметил, что в моей системе это невозможно require 'lib/file.pl' при работе под -T, но require './lib/file.pl' работает.

$ 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"'

Делать это без -T работает в обоих направлениях: $ perl -w -e 'require "lib/file.pl"' $ perl -w -e 'require "./lib/file.pl"'

В грязном режиме, . не является частью @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

Я не мог найти такое поведение в доке. Может кто-нибудь, пожалуйста, скажите мне, где это задокументировано или почему -T не любит . как каталог lib?

1 ответ

Решение

Хм... это на самом деле хорошо задокументировано, я полагаю:

Когда режим загрязнения (-T) действует, "." каталог удаляется из @INC, а переменные окружения PERL5LIB и PERLLIB игнорируются Perl. Вы все еще можете настроить @INC вне программы, используя опцию командной строки -I, как описано в perlrun.

... но это только половина ответа, я полагаю. Причины такого решения приведены здесь:

... проблема с @INC действительно больше связана с SUID-скриптами, чем с CGI-скриптами. Когда у вас есть скрипт SUID, который может выполняться с разрешениями другого пользователя (например, root), Perl автоматически переходит в режим taintmode.

В этом случае сценария SUID было бы огромным нарушением безопасности иметь возможность загрузки библиотек из текущего каталога пользователя. Если в результате выполнения скрипта возникает ошибка, при которой библиотека не найдена в обычном пути к каталогу, пользователь может воспользоваться этим, написав свою собственную вредоносную версию библиотеки, поместив ее в текущий каталог и запустив скрипт SUID из их текущий каталог.

Однако на самом деле это не та же проблема со сценариями CGI. Пользователь не выполняет ваш скрипт из произвольных каталогов. Ваш веб-сервер контролирует, из какого каталога вызывается скрипт. Так что держите "." в @INC это на самом деле не проблема по сравнению с SUID-скриптами, которые автоматически работают в режиме taint.

Другие вопросы по тегам