in reply to Re: Why is my PM package failing?
in thread Why is my PM package failing?

It is called that, and every time I try to run upload.pl with it in there, use Ssbase; my error file returns:

AH01630: client denied by server configuration: /var/www/cgi-bin/upload.pl

I'm not sure what you meant by:

I think at some point search of current directory became not a good thing because of security reasons I don't understand. You may need a use lib "."; to add current dir to the search path for .pm files.

I haven't touched Perl in ages, but I've always kept my pm and pl files in the same directory.

Call me crazy, but last week I had to update my conf files from:

ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
     <Directory "/var/www/cgi-bin/">
         Options +ExecCGI
         AddHandler cgi-script .cgi
     </Directory>

[download]

to

ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
     <Directory "/var/www/cgi-bin/">
         Require all granted
     </Directory>

[download]

just to get my perl files to run from the browser www.example.com/cgi-bin/upload.pl

Any chance they could be related?

Replies are listed 'Best First'.
Re^3: Why is my PM package failing? (security)
by LanX (Saint) on Feb 17, 2022 at 11:17 UTC
    > but I've always kept my pm and pl files in the same directory.

    If that means what I think, than you are having a real security risk.

    Only keep the cgi-scripts themselves inside the configured CGI-bin directory or its sub-tree.

    Modules and other scripts not intended to be directly callable from the World-WW have to be kept outside.

    That's what use lib is for.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

[reply]
[d/l]
Re^3: Why is my PM package failing?
by Marshall (Canon) on Feb 17, 2022 at 03:20 UTC
    Please give a runnable code example of your problem, if you can. Well I guess, upload.pl works if you run it stand-alone, but fails as a CGI script?
[reply]
      SOLVED!

      After more searching, and printing our @INC, I added the line:

      use lib '/var/www/cgi-bin';

      just before calling my module.

      I guess I'll have to do some searching about modifying @INC permanently.

      p.s. Although I don't use Perl regularly enough, last I used it, on the same server...I don't recall having any issues like this before. Guessing in some upgrade something got changed? I thought I saw something about @INC being rebuilt, or restored, every time a new script was run? Something of that nature.

[reply]
[d/l]
        I think it was perl 5.16 where they removed current-dir from @INC. It was less about CGI scripts and more about commandline scripts installed in PATH, where someone could run that command from any directory and get a module pulled in from the current directory by accident (or malice).

        As others have mentioned, you set yourself up for security problems when you put modules alongside your cgi scripts. By default, apache will serve up the contents of your .pm files and let the world look at your code. Even if you add apache configs to block serving your modules, Apache also makes it easy to accidentally reconfigure things in a subdirectory so that suddenly they are visible again. You need to either be really careful with your apache config (now, and in the future), or move your perl modules (and config files and any resource data files) to a different directory that is not being served by apache.

        Also beware of serving your .git/ directory by accident, if you are doing all your work in the cgi-bin dir.

        Also, since you're not following Perl, I'll mention that the latest releases of Perl don't include the CGI module by default anymore, because it has other foot-guns that cause security problems, like calling ->params(...) in list context. If you upgrade your server in the future you might need to install it (either via OS package manager, or via cpanm) The current recommended practices are to use web frameworks like Mojo or Catalyst, but that would be overkill if you just have a few simple scripts you want to keep working. There are also minimalist launched-from-apache replacements like CGI::Tiny or Plack::Handler::CGI + Web::Simple

[reply]
[reply]

In Section Seekers of Perl Wisdom