If you want to run WordPress, you too may want to check whether you’re running the most current version with the latest patches. Better safe than sorry!

But many PHP applications want to write files as well: forums that support uploading files, CMS applications, and many Wikis all create or update files as a normal part of their operation. Since the default permissions don’t allow it, many people run into trouble when trying to develop or install PHP applications that need this ability. This blog post will attempt to show how to do this on our system in a way that is easy to set up and very secure.

On Unix systems like ours, each file has two owners: a user and a group. On our system, the user who owns your files is usually identified to you as “me” and the web server runs as user “web.” Similarly, there are two groups: “me” and “web.” When you are logged in to the ssh server, your default group is group “me” but you are a member of both “me” and “web.” The web server, on the other hand, is limited to the “web” group.

PHP safe_mode imposes a number of restrictions above and beyond standard Unix filesystem permissions. For the most part, these restrictions are designed to prevent multiple sites on a shared host (like ours) from trampling each other. However, if applied properly, they also provided opportunities for you to limit damage to your own site in the event of a bug or exploitable security flaw.

The secret to using this feature properly is to set the proper group ownership on your PHP scripts. If your PHP script is intended to read and write other files in your web space (or related directories), then the script should be owned by the “web” group.

In order for the web server to write to files or directories in your web space, it needs write permissions. As far as the Unix filesystem goes, there are two ways for it to get that: the file can have group “web” and be group writable, or it can have group “me” and be world writable. However, with PHP, that is not sufficient.

On our system, for PHP to be able to write to a file, the group of the file (or parent directory, if creating a file) must match the group of the PHP script doing the writing. If you want a PHP script to be able to write files, you should take the additional step of setting that script’s group to “web.” You’ll also need to make sure that the destination directory for created files has group “web” and that it is group writable.

If this is set up properly, these two steps form a sort of interlock: you specify which scripts are permitted write files, you specify where files are permitted to be written, and the only combination that will succeed is if a permitted script tries to write to a permitted location. Everything else is off limits. This effectively protects the rest of your files from being unexpectedly overwritten by your file-writing scripts, and it prevents other PHP scripts from writing files at all, even if they later turn out to have a security problem that might otherwise allow it.

It’s also possible to get PHP to write files by setting the target file (or directory) to group “me” and giving it world write permissions. However, doing so forgoes all of the above protection, and so it is not recommended. You can also run into problems with this approach if the PHP script intends to create a directory and then create a file in that directory.

All of our member sites have a “protected” directory at the same level as the “public” (aka “htdocs” for older sites) directory that contains your web-accessible material. The “protected” directory cannot be directly accessed via the web, but it has the appropriate ownership and permissions already set for PHP scripts with group “web” to be able to write files. This makes it an ideal, safe place for your site to store and maintain support files without having to worry about what access controls are needed to prevent visitors from accessing those support files directly over the web.

As a final caveat, make sure the PHP scripts you set to group “web” are not group-writable, because that would grant the server permission to modify the script itself, which is generally undesirable.

We have a FAQ entry about using “decoy” sites to forward alternate URLs. This is one method, and probably the easiest, but there are many others that can be useful in different circumstances.

What I’d like to do here is talk about the reasons why we recommend this one and discuss some of the alternatives and when they might be more useful.

The premise of URL forwarding is that a web site should have a single canonical name. Other names might exist, but they’re usually alternate names, or variant spellings, or similar. These names might be common typos you want to catch, easier to type, or whatever. But the actual site accesses should use the canonical name, because that’s best for search engine rankings and long-term recognition of your site.

By far the most common case is when you have a domain name, such as example.com, and you want to use http://www.example.com/ and http://example.com/ to access the site, so that’s the case I’ll focus on here. I’ll also assume that www.example.com is the canonical name of choice. (The temptation to use the bare domain can be very high for some people, but see this FAQ entry for a discussion of reasons why we recommend against it.)

Our FAQ entry suggests creating a forwarding site, assigning example.com to it as an alias, and creating a one-line .htaccess file in its htdocs directory:

RedirectPermanent / http://www.example.com/

We generally recommend creating an alternate site because this is the most efficient approach. With this method, people who enter one of the “wrong” names hit the decoy site and get redirected to the canonical name right up front, and there’s zero extra overhead on any subsequent requests. It’s also really easy to do, and it’s impossible to screw up your working site while setting it up.

Second, we recommend the RedirectPermanent Apache directive for two reasons. The “permanent” redirect code (301) helps keep search engines and the like from continuously trying to index the “wrong” name instead of the right one. Also, the Apache Redirect family works for subordinate URLs. One of the most common redirection mistakes is a setup that will correctly redirect http://example.com/ to http://www.example.com/, but won’t redirect http://example.com/something.html to http://www.example.com/something.html. RedirectPermanent is a one-line solution that handles such cases flawlessly.

One thing that’s come up a couple of times is that once you have a forward for one alternate name, you can add as many other alternate names for the same site as you want. This is easily done by just adding the alternate aliases to the forwarding site.

Now, let’s take a look at an entirely different approach. The ultimate tool for URL rewriting is, of course, the Apache rewrite module, mod_rewrite. It’s possible to use it to accomplish the exact same thing, but without the use of a second site. To do so, you just create an .htaccess file in the site root containing the following:

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www.example.com$ [NC]
RewriteRule ^.*$ http://www.example.com%{REQUEST_URI} [R=301,L]

To summarize how this works in a nutshell:

1) “RewriteEngine on” is needed to enable mod_rewrite.

2) RewriteCond applies a condition under which rewriting will occur. In this case, we want to rewrite if the %{HTTP_HOST} (the content of the HTTP Host: header, which is where the requested domain name lives) does not (the !) match www.example.com from beginning to end (the ^ and $, respectively), without regard to uppercase or lowercase (the [NC]). So this will skip www.example.com and www.ExAmPlE.com but not example.com or any other alias you might want to add.

3) This RewriteRule applies to the whole URL, no matter what it is (the ^.*$) and changes it to the correct name (the http://www.example.com) while keeping the same URI path (the %{REQUEST_URI}) and sends it back to the client as a 301 redirect (the R=301) and skip any other rewrite rules (the L).

The possible big advantage for this method is that it effectively suppresses the use of the default site names we provide (example.nfshost.com), if that’s important to you. It also doesn’t require the existance of an alternate site, if you find that distasteful for some reason. The disadvantage is the extra overhead, which applies to absolutely every request, whether it’s using a URL that needs rewriting or not. (Also, as I personally don’t care for mod_rewrite I consider the use of it a fundamental drawback, but that is more bias on my part than a viable objection.)

The specific question we got was about creating a rewrite site that can handle multiple independent destinations. In this situation, you have a large number of names to rewrite to as well as from. In other words, not just redirecting http://example.com/ to http://www.example.com/ but also redirecting http://other.com/ to http://www.other.com/, all from a single site. RedirectPermanent isn’t smart enough to handle that, but mod_rewrite is.

For this approach, create one “generic” forwarding site from the “sites” tab, and create an .htaccess file in that site’s htdocs directory that looks like this:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^example.com$ [NC]
RewriteRule ^.*$ http://www.example.com%{REQUEST_URI} [R=301,L]
RewriteCond %{HTTP_HOST} ^other.com$ [NC]
RewriteRule ^.*$ http://www.other.com%{REQUEST_URI} [R=301,L]

You can add more sites (to and from) by repeating the RewriteCond and RewriteRule lines. The only real difference between this and the previous example is that we ditched the ! in the RewriteCond lines, meaning that instead of applying to names that don’t match, we apply to names that do.

So that’s three different approaches to the same problem. All work, but they are useful in different circumstances. We can’t document everything in our FAQ, but I’m hoping that one of the uses of our new blog will be the opportunity to explore alternatives like this that might be helpful to our members.