in reply to Why is my PM package failing?

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

[download]
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.

Replies are listed 'Best First'.
Re^2: Why is my PM package failing?
by choroba (Cardinal) on Feb 17, 2022 at 09:56 UTC
    > 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]
[reply]
[d/l]
Re^2: Why is my PM package failing?
by SergioQ (Scribe) on Feb 17, 2022 at 03:16 UTC

    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?

[reply]
[d/l]
[select]
      > 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]
      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]

In Section Seekers of Perl Wisdom