Apache Configuration Help

Byrne Reese on July 2, 2007, 2:45 p.m. Reply

A quick note: One thing to be mindful of is that when “Running Movable Type Outside cgi-bin” that your document root directory has the “AllowOverride” configuration directive set to “All”. That will enable your configuration to for a dedicated MT directory to work.

Byrne Reese on July 2, 2007, 4:11 p.m. Reply

Here is another tip and best practive IMHO:

In a standard Apache install (one installed via RPM or apt) a directory is often created for you: /etc/httpd/conf.d/

Inside this directory you will find configuration files for the various modules and applications that are installed that each require their own configuration settings.

I recommend creating a dedicated mt.conf file in your conf.d directory that will contain all of your Movable Type configuration directives. An example mt.conf file might contain:

   <Directory /var/www/html/mt>
     Options Indexes ExecCGI
     AllowOverride All
     AddHandler cgi-script .cgi
     # For Fast CGI users:
     # AddHandler fcgi-script .cgi
   </Directory>

Nei on July 2, 2007, 7:02 p.m. Reply

Keep in mind that allowing cgi scripts to be run from anywhere can impose an additional security risk to your server.

Byrne Reese on July 2, 2007, 9:14 p.m. Reply

@Nei - This is a very good point and I am glad you brought it up.

Do you not feel that this perception is a relic of a by-gone era when CGI scripts were less prevalent? I mean, PHP and other web based scripting languages do not have any such security restrictions in place (which has contributed a great deal to their wide adoption).

While I think it is wise to be security conscious and to craft a security policy that makes sense for your server, it would be incredibly helpful for someone to articulate the real security threat, and not a theoretical and hypothetical one.

I suppose the advantage of Perl over PHP is that because of Perl’s somewhat ancient legacy with Apache and web scripting is that it is the only language that has unique and special security policy capabilities… I suppose.

Jay Allen on July 5, 2007, 12:28 p.m. Reply

Byrne, you’re absolutely right. As someone who has been doing development on the web back to the Mosaic 0.98 days and who served as Sr. System Administrator for a very large telecommunications company back in the mid-nineties, I can tell you that the stigma against running executable scripts outside of “THE” executable script directory is an artifact of an ugly past where rogue hacks (in the worst meaning of the word) ran their swiss cheesy scripts outside of the only place where sysadmins formerly could bolt things down. This led to years of formmail hijaackings, buffer overflows, 0wnz3red sites and the like.

However, thanks in large part to the workings of the Apache project and the subsequent consolidation of development talent on a single excellent web server (not counting that other one), we have a seriously solid and battle-tested executable environment to work with.

As always, security is a “weakest link” concept. If you have hacks writing crappy insecure code or sysadmins who are either too overworked or too underinvested to focus on security, you’re going to have issues.

The most secure perl app is just as secure as the most secure PHP app (or Ruby, or Python or whatever). The least secure is a wide open door in any language. Where you run your apps only matter if your system administrators haven’t done their jobs and in the case of Low Low Price shared hosting environments, this is sadly all too often the case. You absolutely get what you pay for.

These days like all before it, the big threats are not to well-written, ultra-security conscious apps like Movable Type (and it really is a shining beacon of those characteristics) but hackish scripts (“hey look, I can write bulletin board web software too!”) put together by someone who just knows enough of a particular language to make something work. PHP has garnered he “bad boy” image of late because the barrier to entry is so low and some defaults were historically on the loose side, but even that has changed.

In short (because this hasn’t been), with some notable exceptions, these days it very much comes down to people, not technology, language or placement.

Nei on July 5, 2007, 5:21 p.m. Reply

By the way, using AllowOverride All has other dangerous implications you should be well aware of before mindlessly copying this “recommendation” into your httpd.conf.

It results in anyone with access to .htaccess files (which is also especially Movable Type itself) to reconfigure almost your whole webserver. We’ve seen some effects of that when the beta wrote .htaccess files disabling user-set error pages.

This option can even crash your webserver if putting some directives in your .htaccess (such as mod_rewrite configuration).

Nei on July 6, 2007, 2:15 a.m. Reply

Why is it then, that you’re apparently not using your own-recommended setup for this website and sixapart.com? Looks to me like there’s still the crufted /cgi-bin/ in your Movable Type paths.

Also keep in mind that setting +ExecCGI does not mean only that the Movable Type scripts will be executed. It doesn’t even mean that only Perl scripts will be executed. In fact, any program the user manages to stuff in their public_html can be executed.

I don’t think that allowing PHP to be placed outside of the /cgi-bin/ has in particular contributed to its popularity.

Other factors such as easy embedding in html, the lack of need to “chmod” the files, a general friendliness towards illiterate and a good coverage of inbuilt functions are much more likely to be decisive factors.

While I acknowledge that it is an “easy way out” for intermediate or experienced website managers, I like to focus on two cases:

You might want to give people the power to blog.

In this case, it isn’t generally wise to also give them the ability to run arbitrary scripts, which they could when ExecCGI is set.

(I don’t think you allow custom scripts on your hosted services either, do you?)

Granted, you could set up suEXEC (you should do that regardless the case) and then blame it on the people when they get owned.

But it’s mostly more cozy if you don’t have to deal with these issues.

You consider yourself a “pro” and are running the site just for yourself.

I can see how it might be tempting to allow scripts to be run from anywhere. But most of the time this doesn’t even make sense, because scripts are vastly different from “html with a bit of scripting embedded”.

In summary, there is little to no reason to avoid the cgi separation.

I think we can assume that most people would want to keep their mt*.cgi files seperate from their blog anyway. This means it is easy to designate just the directory in which you placed Movable Type as a Script directory.

Because of the limitations Apache places upon cgi-bin directories mounted by the ScriptAlias directive, it is often easier to “bless” a directory running Movable Type with the ability to execute CGI scripts.

Apologies for sounding so harsh, but this is absolutely nonsense.

• Apache doesn’t place any particular restrictions on ScriptAlias directories. The main difference is that every file inside a ScriptAlias directory may be considered as a script candidate, which has the most commonly observed effect of it being difficult to have images and stylesheets inside a ScriptAlias‘d directory.

• To quote the docs:

  [The ScriptAlias] configuration is essentially equivalent to:

  [...]
  <Location /cgi-bin >
     SetHandler cgi-script
     Options +ExecCGI
  </Location>

  • But since Movable Type is already designed for this particular set-up and keeps all the static files in a seperate mt-static directory, it is pretty straight-forward to move the mt-static folder outside of the cgi-bin.

  You could further facilitate this process by shipping the MT-*.tar files with a directory structure such as follows:

  /cgi-bin/movabletype/mt.cgi
  /cgi-bin/movabletype/...
  /mt-static/...

  In comparison, a directory configured like this…

  <Directory /var/www/html/mt>
     Options Indexes ExecCGI
     AllowOverride All
     AddHandler cgi-script .cgi
     #[...]
  </Directory>

  …uses the file extension to decide which files are to be treated as scripts and which ones are to be served naturally.

  If you even use a configuration which is further recommended by these docs like the following:

  <Directory /path/to/movabletype>
     Options Indexes ExecCGI
  </Directory>

  …you turn on “Indexes”, which means that people can see all the content in a directory when there is no index.html file.

  Now let’s take a look at the benefits of using a designated cgi-bin directory. (By the way, I’m not argueing that you should name your cgi-bin directory “cgi-bin”. Feel free to name it “movabletype” or whatever seems appropriate.)

  • If we now take a look at the files included with Movable Type, you’ll see that there are quite a lot of files outside of the mt-static directory which do not end in .cgi.
  • We’ll also find that most directories do not contain an index.html file.

  This means that on a webserver configured in such a fashion like recommended by these docs, people are able to view in plain source the content of all the files in your Movable Type installation. (Even if you omit the Indexes, people will still be able to view the content of files.)

  Amongst other things, this facilitates infringing intellectual property rights on custom-made or paid-for Movable Type scripts/plugins or might reveal the source of “linked” template files and other files that random people do not need to have access to.

  A further potential issue is that bad things can happen if your webserver config goes awry and you’ve shuffled the Movable Type files directly into your public_html directory.

  The most endangered file in this case is your mt-config.cgi which contains your database password in clear text.

  I can hear you laugh, “What? There is no way something like this will happen to me!”. But should for some reason the Options +ExecCGI directive become disabled (for example during a Debian Apache 2.0 to Apache 2.2 upgrade), suddenly your Movable Type configuration will be readable all over the web!

  Using a designated cgi-bin directory outside your public_html can further help to protect you from such misfortune.

  Another nice benefit of not detecting scripts by extension is that you can easily offer self-written .cgi scripts for download on your website without having to change the extension to .txt or wrapping them up in a .zip-archive.

  Do yourself a favour and use a designated script directory; the price is small and it stops you from accidentally uploading programs that weren’t mean to be run.

  Personally, our public_html directories of course have no ExecCGI permissions.

  • Futhermore, our Movable Type and other script installs are being kept totally outside of the publicly accessible directories.
  • Also, the script files are not owned by the www-script user and such it is imposible for malicious scripts, accidental misfortunes or Movable Type to modify or delete the script files. The only thing the scripts can tamper with are the files in the public_html directories.
  • Finally, by this separation we can also achieve a more easy access control. Only our script administrators may tamper with the installed scripts, while our other staff can copy any files they desire into the public_html without needing to take any extra care.

  Ultimately, rather than trying to educate people, make it so that they don’t need to be educated is always a much more wise approach.

  Of course, this cannot protect you from putting malicious scripts inside your cgi-bin, but at least you need to think about what you put inside there.

  PS: There seems to be a mysterious problem with my comments. This is already the second time one of my submissions got lost/ wasn’t published. I wonder why?