Can't locate strict.pm

     Back with another interesting Perl endeavor today. I've been working on a triple DES decryptor and ran across a module, Mcrypt, that supported triple DES through mcrypt. (Please understand that 3DES is broken and shouldn't be used for ANYTHING). Sadly this module isn't currently in Devuan's repos. Never the less I installed all the necessary dependencies (libltdl-dev libmcrypt-dev) to get cpan on my system and then ran cpanm Mcrypt. No issues so far then I try to run some previously working Perl code.

┌─[aut0exec@Devuan]─[~/Projects/Perl]
└──╼ $./Do_Stuff.pl 
Can't locate strict.pm:   /usr/local/share/perl/5.32.1/strict.pm: Permission denied at ./Do_Stuff.pl line 24.

    That was a new one for me. So I jumped into the terminal and took a look in the directory it was complaining about to see if strict.pm was there. While the /usr/local part was already odd to me, I checked things out anyways. To my surprise there wasn't anything in that directory let alone strict.pm. At this point I took to Google and was greeted with the normal lack of useful results but some indications that there might be something wrong with the @INC list of paths for Perl. Reading through Perl's documentation, it was described that one can list out the configured paths in @INC.

┌─[aut0exec@Devuan]─[~/Projects/Perl]
└──╼ $perl -V
Can't locate Config.pm:   /usr/local/share/perl/5.32.1/Config.pm: Permission denied.
BEGIN failed--compilation aborted.

    Umm... What? What in the world did Cpan do!? I kid, this turned out to be a user error but at the time I was frantically searching for a way to fix this system as NONE of my Perl code was working all of a sudden.... except for the root user! So the plot thickens. At this point that glaring Permission denied message started to kick my sysadmin troubleshooting gears in a different direction. perl -V as root shows the following paths as the included paths for Perl to search for modules.

  @INC:
    /etc/perl
    /usr/local/lib/x86_64-linux-gnu/perl/5.32.1
    /usr/local/share/perl/5.32.1
    /usr/lib/x86_64-linux-gnu/perl5/5.32
    /usr/share/perl5
    /usr/lib/x86_64-linux-gnu/perl-base
    /usr/lib/x86_64-linux-gnu/perl/5.32
    /usr/share/perl/5.32
    /usr/local/lib/site_perl

    Interesting so it fails on the third entry for normal users? Wonder what the permissions are!?

┌─[aut0exec@Devuan]─[~/Projects/Perl]
└──╼ $ls -l /usr/local/share/perl/
total 4
drwxr-x--- 7 root root 4096 Aug 24 09:02 5.32.1

    Well well well! That would explain both behaviors I was seeing and since this is folder that is supposed to be accessible to all users of the system, I went ahead and allowed for world to have the ability to read/execute into this directory with chmod o+rx /usr/local/share/perl/5.32.1. Then running perl -V again I was pleasantly surprised to see the expected Perl config output! Now to confirm that my other Perl code was working properly again.

┌─[aut0exec@Devuan]─[~/Projects/Perl]
└──╼ $./Do_Stuff.pl 
[INFO] Doing all the things...

    Whoo! That's what I wanted to see! Turns out that my root user's umask value of 0027 came back to bite me. Since I hadn't installed anything with cpan before, the folder at /usr/local/share/perl/5.32.1 didn't exist so it was created. The umask value however would remove all permissions for the world group upon folder creation though! Seems odd that folder permissions would completely tank the perl interpreter from running but I'm sure there's a good reason from the devs for this behavior. None-the-less, hope this helps anyone else who runs across similar behavior to possibly correct their system.