Due to faulty configuration as done by mod_perl's ebuild while doing config, the
standard configuration leaves the main script directory /perl (and optionally,
/cgi-perl) indexable. This is a minor security flaw.
The error does not affect users' mod_perl script directories, only the system one.
The section of apache's commonapache.conf that are faulty are:
Removing the "/*.pl" ending on those two rows resolves the issue.
Since I have no experience with ebuilds, I can't send any fixed ebuild. My
mod_perl package is now version 1.27, but i'm unsure if it's been upgraded since
I did the ebuild config. In that case it's been upgraded only once.
Can you do a test for me? Add the /*.pl back (as that was to register the
extention) and add this section before the perl module configs:
Lemme know the results.
Sorry for the delay, been on a vacation.
That works... I've now tested a section like this:
#set Apache::PerlRun Mode for /cgi-perl Alias
(all inside the <IfModule> section), which seems to work. I can't get an index
listing, and the scripts still execute. The same should work for the /perl
section, though I haven't tested it.
*Important note*: I still consider this bad security practice, since it leaves
some files readable. AFAIK the recommended option is to use the /perl and
/cgi-perl directory matches. Consider the following:
script access.pl uses module accessed.pm.
loading access.pl will run the script as expected. Loading accessed.pm, will
give the source of that document, however - not a good thing. Using <Location
/perl> (or similar) will run the module however, which does nothing but load the
module, return true, and the browser will most probably show some error like
"The document contains no data" (Mozilla does). If an attacker can guess the
name of a module used or somehow obtain this information, that'd give a platform
This is an even more minor issue than the original one, but is there a good
reason to only allow .pl files as scripts in /perl?
This appears to be fixed in commonapache.conf.