Managing Default File Permissions

WE is built around security

On "other hosts", there is a custom to make all files world-readable or even world-writable. This means that users of a site can get to a sensitive information or even corrupt parts of this information. Also, if one site gets compromised as a result of a malicious activity, other sites may also become compromised.

A side effect of this is 403 errors for files that need to be world readable (i.e. js or css files).

One common solution to this problem is to use a less stringest umask. We don't recommend using a less stringent umask: for our sites to remain secure, it is advisable to adhere to the least privilege principle (http://en.wikipedia.org/wiki/Least_privilege), which suggests making files or other information accessible only when really needed. That is, our recommendation is to create files that are not group-readable or others-readable by default, and explicitly change permissions on static web accessible data to make them readable to the apache process.

Fixwebperms Solution

In order to make changing permissions easier, we have a special script, /usr/local/bin/fixwebperms.sh, which is passed a directory name and sets correct permissions for all files and subdirectories. Every time you add files or directories and want to make directory contents web-accessible, just type:

The script makes static files world-readable, but keeps php scripts user-readable only.

One should avoid using this script (or chmod) on large directories too often if not really needed: the chmod system call updates ctime of all files on which it is run, even if their permissions do not change; this makes programs that perform incremental backup think that all files have been changed, thus making the size of backup dumps unnecessarily large.

In other words, fixwebperms.sh is to be used infrequently or on the required sub-trees only because it is unfriendly to incremental backups (increasing the size of backup dumps).