danmcb has asked for the wisdom of the Perl Monks concerning the following question:

afternoon brothers of the cloth (or whatevr time it is with you)
I'm working on a web app which is mostly perl cgi. I use apache on my machine at home, with a dir 'dev' for my own latest code, another slightly more stable version on the root of the server that other peeps see. I also have some stuff in libraries. For the stable code this is at /usr/local/lib/site-perl - my unstable version is in the 'dev' directory.
The problem was to make my dev code all see the local library, not the one in /usr ... to do this I have
use lib "..";
in my files. It does nothing in the stable version, as there are no lib files at the server root, but in my dev code my unstable lib is seen before the stable one. Then I can commit and export, see the right code with no changes.
Of course, it breaks my scripts (all with -T) the moment I call sendmail. Took me a while to figure out. OK. So I change to:
use lib "/var/www/dev";
where necessary - but I still get the "insecure path" message. Hmmm. Why? ($ENV{PATH}, printed out right before taint complains, is
/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games)
And what is a better way of getting to say which library should be seen. I need something like a config file that specifies locations perhaps? I'm sure there is an easy, clean way ..
Many thanks, and happy $%@ing.

Replies are listed 'Best First'.
Re: taint mode, libraries and file path
by dave_the_m (Monsignor) on Aug 21, 2005 at 22:36 UTC
    I still get the "insecure path" message. Hmmm. Why?
    $PATH is automatically tainted at startup time, regardless of its contents. It is necessary to explicitly set $ENV{PATH} before you call an external command.

    Dave.

[reply]
Re: taint mode, libraries and file path
by fizbin (Chaplain) on Aug 22, 2005 at 02:07 UTC

    In case the previous post wasn't clear, you can go back to using: 

    use lib "..";

    [download]
    In your development environment. That has nothing to do with the message you're getting. As was said, you need to set $ENV{PATH} to some value before doing a call to any external program.

    Incidentally, the reason you haven't hit this in production is likely because your production server is calling CGI scripts with no PATH set in the environment. This means that your production scripts will suddenly break if someone tweaks the existing Apache configuration file and adds:

    SetEnv PATH /bin:/usr/bin

    [download]

    to the Apache configuration. This is a ticking bomb, and waiting for someone else to break it in this fashion. You might want to put:

    $ENV{PATH} = q[/bin:/usr/bin];

    [download]
    at the top of your production scripts as soon as is feasible. 
    --
@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/

    [download]
[reply]
[d/l]
[select]
      In fact I'd go further and suggest explicitly wiping out %ENV, and only setting the items that you need. That will eliminate time bombs from various modules that might use environment variables in unexpected ways. (Particularly cases where after an upgrade, the module adds an environment variable that it didn't use before.)

      Note that if you really did want something like PATH to be settable, you can untaint it (presumably with a sanity check) and set the value to the untainted version.

[reply]
        Good point. Note that perl's taint mode doesn't guard against other wild variables, such as LD_LIBRARY_PATH or LD_PRELOAD, both of which are on many systems just as dangerous as PATH. 
        --
@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/

        [download]
[reply]
[d/l]

Back to Seekers of Perl Wisdom