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

I want to start to move some of my functions over to a separate module. So I created the simplest of ones, just to build up from there. However no how hard I try, my already working Perl module "upload.pl" fails if I add "use Ssbase;" to it. And of course it works if I remove that line.

I have tried everything in that, they're all in the same directory, I've set the permissions to Ssbase to 777, the user and group to www-data, etc.

I've even tried taking everything out of the package other than the name line, and the 1; line.

I'm so befuddled and angry that I can't do anything else!

package Ssbase; require Exporter; use strict; use CGI; no warnings 'uninitialized'; our @ISA = qw(Exporter); our @EXPORT = qw(justReturn); sub justReturn { return 0; } 1;

Replies are listed 'Best First'.
Re: Why is my PM package failing?
by Marshall (Canon) on Feb 17, 2022 at 02:51 UTC
    This file should be named "Ssbase.pm".
    Call it like this:
    use strict; use warnings; use Ssbase; my $ret = justReturn(); print "$ret\n"; #prints 0
    I don't know why there is no warnings 'uninitialized'; because you aren't using warnings to begin with. But that doesn't matter.

    Update: I remember something that may affect you, 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. My testing didn't need that, but you might.

      > because of security reasons I don't understand

      Searching for modules in the current directory is insecure, because you never know what the current directory is. It's not the directory where the script is, it's the directory where you are when you run the script. The current directory might be world writable (think /tmp), so anyone can insert a malicious module. Some scripts work without a module, but they try to load it (e.g. for better performance); on a system without the module installed, the malicious module would be picked up.

      See rt#127834 for details.

      map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

      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>

      to

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

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

      Any chance they could be related?

        > 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

        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?