C:\>perl -le"print for @INC"
c:/Perl/lib
c:/Perl/site/lib
.

C:\>perl -Tle"print for @INC"
c:/Perl/lib
c:/Perl/site/lib

C:\>
[download]

After reading your little blurb, I went back and looked at my configuration files for my editor. I configured three different Perl launch options. The primary one I've been using for testing/checking my scripts straight from the editor has -wT (it launches Perl from a command prompt). When I run the script via Apache, I've been leaving off -wT.

I think I did it this way because a problem I can't figure out is when I run the script from my editor, Perl balks at having #!perl -T. Perl claims declaring -T is too late. But that line works fine with Apache. I'd configure Apache to include -T automatically (if it was possible), but the production server doesn't have Perl configured that way. Oh well.

----
Thanks for your patience.
Prove your knowledge @ HLPD

perl -e 'print "@INC\n"'
[download]

So I went back and removed the lib "./" decleration. And voila! My problem didn't come back. Ggrrrrrr!

I have no idea what was wrong before. Nor why I can't recreate the problem at this hour. I'm tired, I'm going to bed. This has been a horrible day for me. I spent all day fussing with existing flaky code and none actually writing new code. Might be time to repair the Linux box and get it running again.

So I guess the answer to my question: There is probably minimal security risk, it's there by default. Though I concure with hbo that I feel more comfortable with an absolute path. I just hate changing path information when I move the script from the Windows box to the UNIX box. Howver, I don't think I agree with him about . being a security risk with bogus modules place in the CWD. If someone breaks into the system and is able to place bogus modules in the CWD, I seriously doubt that not having . in the @INC would make any sort of difference. That's just my thinking though. I could be way wrong about that logic train.

Sorry you had an unproductive day. I've had a few like that myself.

After correcting myself and being corrected by others, I beg to differ slightly with your final conclusion.

  use lib "./";
[download]

actually does have security implications. If "./" is first in the module searh list, then a file called,for example, "CGI.pm," in the directory your script runs in, would alter the effect a use CGI; directive would have, if it appeared after the first use statement. In other words, you could be vulnerable to a trojan horse attack.

Of course, since "./" appears in the load path by default after all the other paths, this danger is considerably lessened. But for myself, I still dislike relying on a relative path to load code. When you don't have absolute control of the working directory your script will run from, it's better to use absolute paths for security's sake.

I don't think that '.' in @INC is a security risk in the same way as '.' in $ENV{PATH} would be.

With PATH there is a risk of root cd'ing into a directory and running a trojaned ls compromising the system. An attacker might have write access to their home directory, which would be expected (under the assumption that the attacker is an authorised user)

With @INC if the attacker can write a trojaned CGI.pm then they would have write access to the directory, and the could just as easily unlink the script it self and replace it with a trojaned version.

Correct me if I'm missing something.

• FreeBSD 5.0 (perl v5.8.0)
• Darwin(perl v5.8.1)
• Redhat (perl v5.8.3)

unshift(@INC, "./");
[download]

unshift would be bad. That puts "./" at the start of the search list, which means standard module names could be overridden by placing bogus ones in the CWD.

push @INC,"./";
[download]

Better, but it isn't going to affect use statements, since those are evaluated at compile time. So,

use lib "./";
[download]

is even better. But best is:

use lib /some/absolute/path/that/you/control;
[download]

Update: use lib "./" is worse than unshift @INC,"./" because it also prepends "./" to the search path, but does so at compile time, where it can affect other use statements.

BEGIN {
    eval { require "Some::Optional::Module" }
}
[download]

Dave.

hbo@owen|1347> perl -e 'print join "\n",@INC'
/usr/lib/perl5/5.8.1/i686-linux
/usr/lib/perl5/5.8.1
/usr/lib/perl5/site_perl/5.8.1/i686-linux
/usr/lib/perl5/site_perl/5.8.1
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl/5.6.0
/usr/lib/perl5/site_perl
[download]

Since use et al take the first match, there shouldn't be a danger of loading a bogus standard module if you have "."at the end of @INC. It's similar to having "./" at the end of your Unix PATH, however, in that what "./" means changes with your CWD. This opens up a possibility of loading a non-standard module that you don't expect. If you have root, (or administrator for *ix challenged) it's good practise to install your modules in the site_perl directories.

For my personal software, I create and use a ~/lib/perl and include the following at the top of my scripts:

use lib /path/to/my/home/lib/perl;
[download]

Are you sure you didn't miss the dot on the end? Please run this: perl -e 'print join "\n",@INC,"\n"'

Yup, you are correct. The "." appeared at the beginning of my prompt on the next line and I missed it.