Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have two serveers. Server 1 runs Apache 2.2 and mod_perl 2.0.4. Server 2 runs Apache 2.0 and mod_perl 1.99. They have nearly identical conf files. The perl section of the vhost looks like this:

    SetHandler perl-script
    PerlResponseHandler ModPerl::Registry
    Options +ExecCGI

If I put a cgi script in the designated perl directory of Server 2 chmodded to 644, I can't access the file through the web browser. I get Forbidden as the error. That's the behavior I'd expect. I have to chmod it to 755 first.

However, if I put the save script in the directory for cgi scripts on Server 1 chmodded to 644 the server just executes the script. It doesn't seem to care what the file's permissions are only what the directory is set to.

All files are owned and grouped in root and apache is running under a separate user. The directory is chmodded 755 and also belongs to root.

My question is, is there a way to make the behavior identical and is this a potential security risk on Server 1? Or is there a generally better way I should be doing this?

share|improve this question
up vote 0 down vote accepted

mod_perl isn't CGI, so neither +ExecCGI nor executable permissions actually matter for it. The reason that you see different behaviour is that in verstion 1.999_02 mod_perl developers changed their mind about the executable bit:

ModPerl::Registry no longer checks for -x bit (we don't executed
scripts anyway), and thus works on acl-based filesystems. Also
replaced the -r check with a proper error handling when the file is
read in. [Damon Buckwalter <>]


share|improve this answer

If Apache is told by the ExecCGI option that it can execute a cgi in a directory, it will. Normally a perl script doesn't need to be executable for Apache to run it, only readable. It's possible that the older 1.99 version of mod_perl implements something like the Apache 'XBitHack' but that behavior is now non-standard. Are you saying that the directory that gave you a 403 error was 644? No one but root can navigate into a 644 directory, so that's to be expected. But if you're saying the file is 644, and the directory is at least 111, then the reason for the 403 error could be the 'XBitHack' or something else hard to determine from the information given.

The newer behavior is safer and more flexible, because it's generally a good idea to minimize the permissions of all filesystem objects, and non-executable scripts located in an ExecCGI directory are executable only by Apache. If you don't want them to be, don't put them in there or don't set the ExecCGI option. If for some reason you want to let them also be shell-executable, you can then set the bit.

share|improve this answer
Unfortunately the first bit is not true: CGI scripts need to be executable. mod_perl isn't CGI though, so doesn't care. – Dennis Kaarsemaker Aug 25 '13 at 17:33
@Dennis Kaarsemaker: thanks. I've always used 'cgi' very sloppily and generically, and I'm not a perl programmer, but I've always assumed mod_perl checked ExecCGI. I never tested it until today. You're right! I like your answer better anyway. – Peter Rowntree Aug 25 '13 at 21:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.