1

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:

<Location/perl>
    SetHandler perl-script
    PerlResponseHandler ModPerl::Registry
    Options +ExecCGI
</Location>

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?

2 Answers 2

0

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 <[email protected]>]

From http://perl.apache.org/dist/mod_perl-2.0-current/Changes

0

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.

2
  • Unfortunately the first bit is not true: CGI scripts need to be executable. mod_perl isn't CGI though, so doesn't care. Aug 25, 2013 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. Aug 25, 2013 at 21:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .