Building your own version of perl is indeed the best way to know what is in your perl, but it also keeps you safe from system perl updates.  But what about when your perl breaks in strange ways?

From my apache error_log:

Can't load '/opt/perl510/lib/5.10.1/i686-linux-64int/auto/B/B.so' for module B: /opt/perl510/lib/5.10.1/i686-linux-64int/auto/B/B.so: failed to map segment from shared object: Permission denied at /opt/perl510/lib/5.10.1/i686-linux-64int/XSLoader.pm line 70.

Can't load '/opt/perl510/lib/5.10.1/i686-linux-64int/auto/IO/IO.so' for module IO: /opt/perl510/lib/5.10.1/i686-linux-64int/auto/IO/IO.so: failed to map segment from shared object: Permission denied at /opt/perl510/lib/5.10.1/i686-linux-64int/XSLoader.pm line 70.

Can't load '/opt/perl510/lib/5.10.1/i686-linux-64int/auto/Fcntl/Fcntl.so' for module Fcntl: /opt/perl510/lib/5.10.1/i686-linux-64int/auto/Fcntl/Fcntl.so: failed to map segment from shared object: Permission denied at /opt/perl510/lib/5.10.1/i686-linux-64int/XSLoader.pm line 70.

The script that I was writing works correctly when run from the shell.  But when called under apache, forget it!

The clues to what is really happening here can be found in the setroubleshoot logs:

setroubleshoot: SELinux is preventing the send_alert.pl (httpd_sys_script_t) from executing /opt/perl510/lib/5.10.1/i686-linux-64int/auto/Data/Dumper/Dumper.so. For complete SELinux messages. run sealert -l 15f88a0f-9133-49de-8946-24d241a0219c

SE Linux is here to ruin your day!  So turn it off already.  That seems to be the solution that everyone else uses when they confront SE Linux issues…

sealert explains:

sealert -l 15f88a0f-9133-49de-8946-24d241a0219c

Summary:

SELinux is preventing the send_alert.pl (httpd_sys_script_t) from executing /opt/perl510/lib/5.10.1/i686-linux-64int/auto/Data/Dumper/Dumper.so.

Detailed Description:

SELinux has denied the send_alert.pl from executing /opt/perl510/lib/5.10.1/i686-linux-64int/auto/Data/Dumper/Dumper.so. If send_alert.pl is supposed to be able to execute /opt/perl510/lib/5.10.1/i686-linux-64int/auto/Data/Dumper/Dumper.so, this could be a labeling problem. Most confined domains are allowed to execute files labeled bin_t. So you could change the labeling on this file to bin_t and retry the application. If this send_alert.pl is not supposed to execute /opt/perl510/lib/5.10.1/i686-linux-64int/auto/Data/Dumper/Dumper.so, this could signal a intrusion attempt.

Allowing Access:

If you want to allow send_alert.pl to execute /opt/perl510/lib/5.10.1/i686-linux-64int/auto/Data/Dumper/Dumper.so: chcon -t bin_t '/opt/perl510/lib/5.10.1/i686-linux-64int/auto/Data/Dumper/Dumper.so' If this fix works, please update the file context on disk, with the following
command: semanage fcontext -a -t bin_t '/opt/perl510/lib/5.10.1/i686-linux-64int/auto/Data/Dumper/Dumper.so' Please specify the full path to the executable, Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this selinux-policy to make sure this becomes the default labeling.

While SE Linux can be frustrating at first, once you know where to look and what to for in the setroubleshoot logs, you'll soon find that it tells you what you need to do in order to get things working correctly.  And when someone tells you to turn off SE Linux as 'the fix' to the SE Linux problem, let them know that isn't a solution.