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: <Location /perl/*.pl> #<Location /cgi-perl/*.pl> 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: <Location /perl> Options -Indexes </Location> Lemme know the results.
Sorry for the delay, been on a vacation. That works... I've now tested a section like this: <Location /cgi-perl> Options -Indexes </Location> #set Apache::PerlRun Mode for /cgi-perl Alias <Location /cgi-perl/*.pl> SetHandler perl-script PerlHandler Apache::PerlRun Options ExecCGI </Location> (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 for attack. 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.