Cooking with Apache, Part 3

O'Reilly Book Excerpts: Apache Cookbook

Cooking with Apache, Part 3

Editor's note: In this third and final batch of recipes from the recently released Apache Cookbook, authors Rich Bowen and Ken Coar provide solutions to problems related to authentication, symbolic links, and the ever-troublesome trailing slash. And if you missed any recipes from the first two batches, we've provided links and descriptions to those recipes at the end of the page. Enjoy.

Recipe 10.8: Requiring Authentication for a Proxied Server

Problem

You wish to proxy content from a server, but it requires a login and password before content may be served from this proxied site.

Solution

Use standard authentication techniques to require logins for proxied content:

ProxyPass "/secretserver/" "http://127.0.0.1:8080"
<Directory "proxy:http://127.0.0.1:8080/">
    AuthName SecretServer
    AuthType Basic
    AuthUserFile /path/to/secretserver.htpasswd
    Require valid-user
</Directory>

Discussion

This technique can be useful if you are running some sort of special-purpose or limited-function web server on your system, but you want to apply Apache's rich set of access control and its other features to access it. This is done by using the ProxyPass directive to make the special-purpose server's URI space part of your main server, and using the special proxy:path <Directory> container syntax to apply Apache settings only to the mapped URIs.

Recipe 11.6: Optimizing Symbolic Links

Problem

You wish to balance the security needs associated with symbolic links with the performance impact of a solution, such as using Options SymLinksIfOwnerMatch, which causes a server slowdown.

Solution

For tightest security, use Options SymlinksIfOwnerMatch, or Options -FollowSymLinks if you seldom or never use symlinks.

For best performance, use Options FollowSymlinks.

Discussion

Symbolic links are an area in which you need to weigh performance against security and make the decision that makes the most sense in your particular situation.

In the normal everyday operation of a Unixish operating system, symbolic links are considered to be the same as the file to which they link. [1] When you cd into a directory, you don't need to be aware of whether that was a symlink or not. It just works.

Apache, on the other hand, has to consider whether each file and directory is a symlink or not, if the server is configured not to follow symlinks. And, additionally, if Option SymlinksIfOwnerMatch is turned on, Apache not only has to check if the particular file is a symlink, but also has to check the ownership of the link itself and of the target, in the event that it is a symlink. While this enforces a certain security policy, it takes a substantial amount of time and so slows down the operation of your server.

In the tradeoff between security and performance, in the matter of symbolic links, here are the guidelines.

If you are primarily concerned about security, never permit the following of symbolic links. It may permit someone to create a link from a document directory to content that you would not want to be on a public server. Or, if there are cases where you really need symlinks, use Options SymlinksIfOwnerMatch, which requires that someone may only link to files that they own and will presumably protect you from having a user link to a portion of the filesystem that is not already under their control.

If you are concerned about performance, then always use Options FollowSymlinks, and never use Options SymlinksIfOwnerMatch. Options FollowSymlinks permits Apache to follow symbolic links in the manner of most Unixish applications - that is, Apache does not even need to check to see if the file in question is a symlink or not.