Files, directories, users, groups, other users, ownership, permissions.
This is fundamental Linux stuff and, regardless of your self-hosting type – from shared to dedicated – you have to live and breathe the topic because, if you're not clued up about your server's permissions structure and, in turn, the security of your web files, then you're begging for trouble.
Here's the deal.
- Files and users 101
Linux is a bunch of files. Everything is a file. Even directories are files, merely listing other files (although that's being pernickety).
Actually, two things are not files, users and groups. We'll consider those now. When a user is created, a namesake group is also created by default. So you may have the username superbob and be a member of the group superbob. When user superbob creates a file, rights (aka privileges) are automatically dished out:
- user – superbob owns and can have various user permissions over the file
- group – superbob‘s namesake group owns and may have different rights and that is convenient because selected users can be added to that group to share particular permissions
- Every other user has no ownership and gets a third set of other permissions
With any of these three classes it can equally be stipulated that they have no rights.
On a shared server, there's only one human user per hosting plan: you. As with any hosting arrangement, by default you are a member of your user's namesake group. You cannot add more users or groups, nor modify ownership of files. You do own all the files in your account though and can specify permissions for these.
Users with privilege escalation rights – in other words that can assume root which is the case with unmanaged hosting such as with a VPS or dedicated server – can perform administrative tasks. As we may surmise, such sweeping powers are both useful and dangerous.
- Ownership and permissions
So what sort of rights, permissions, privileges or whatever else they are called do we have? What can we actually do with files?
We can read files, change them when we write to them or execute them into action. This can be illustrated using what's called symbolic notation, like this:
user group other somefile rwx rwx rwx
rwx is shorthand for read, write, execute … so in this example full privileges are afforded to the file owning user, to the group and to every other user. Sounds risky? It is, a bit like flinging open all the windows before leaving home. Here's how this looks in a terminal:
So that's three sets of rwx, totaling nine characters. This information also confirms the owning user is superbob and, next to that, that the file's owning group is the group called superbob.
But rwxrwxrwx is quite a mouthful, huh? To help with that, we can express this in what's called octal notation which, in this case, translates as 777 permissions, as we shall see.
Here's another example, this time with a more familiar file:
This time, only the Apache group www-data has any right to do anything at all – reading the file only – and with some systems this ultra-tight privilege set can work for wp-config.php. We would express this, in octal notation, as 040 permissions.
- Translating symbolic to octal notation
Consider a single set of symbolic permissions:
The sum total of that is 7. So how? Here's the formula (do learn this by heart):
r 4 w 2 x 1
read corresponds to a value of 4, write to 2 and execute to a value of 1. rwx, equating to full rights, tots up to 7. Remember those rwxrwxrwx permissions? That equates to the dreaded 777. Don't use it.
Here are sensible permissions for a regular WordPress theme file:
The superbob user has read-write access, there is read-only for the Apache group, www-data, and all other users are granted read-only. You would present that in a table like this:
u g o r 4 4 4 w 2 x
Totted up, that gives us an octal value of 644 permissions.
- Using change mode to modify permissions
You may have changed the mode of a file, using octal notation, from a control panel's file explorer or using an (S)FTP client. Here's how it's done from the terminal:
That tells Linux to give the user read-write access, denying anyone else. You can equally use symbolic notation.
To add read access for the group to the existing 600, do this:
That group+read command edits the rights to 640.
To deny the user permission to write:
The user-write command reduced rights to 440.
Finally, to permit all three classes to write to the file:
Using all+write we've changed rights for the user, group and other, ending up with 662.
- WordPress permissions
Given the theory, the practice is easier. We like that.
Remember, least privileges are what we want. You can escalate those if necessary but, understand, 777 permissions are simply begging for abuse. On a live site, never never never!
Those Automattic types recommend not setting permissions above 755 for directories and 644 for files. At the terminal we ensure those with two commands:
Using sudo to assume root privileges, those commands find a path and then, whether for type directories or type files, they execute the change of mode. For instance, here, all the folders below /path/to/WP-root/ would be given 755 permissions and all files below the path, in any underlying folders, are set at 644.
- Permissions case study: super-tight wp-config.php
For any file the principle is the same: deny all users, including you, to the utmost degree. This helps to protect the file and to limit damage should it become compromised. How restrictive we can be, though, depends on who needs what access.
Take wp-config.php. Only Apache needs read access to the file. That’s it, that’s 040 where Apache is the group. On shared servers, where php files run not under Apache but with your privileges, similarly we may use 400. Then again, sometimes permissions need raising, such as to allow you to write to the file as well as to read it.
Because server configurations vary there can be some hit and miss as we try super-squeezed rights, relaxing them until the site functions. This isn’t ideal because, in the process, there may well be a few seconds of downtime, the white screen. At your host’s forum, though, probably the least possible privileges are discussed so take a peak.
Given the logic of all this, wp-config.php on shared servers may have a permissions value as low as 400, maybe 600 but, denying access to other users, never above 750. Unshared servers would accept between 040 and 640, depending on your needs.
Short of a precise setting, the procedure of this trial and error is to flush your browser's cache, change the permission and then browse to the site. Problems? Try again with a notched up number.
- Using change owner to modify ownership
Shared types can't change owner, sorry. Nonetheless, we should all understand the gist:
What superbob did here was to retain his user-owner privileges over somefile.php while giving Apache the group rights to share with any other user in the www-data group. There is a tiny change to this syntax to reassign ownership of a folder and its underlying contents in what we call a Recursive change:
So now, at a stroke, Apache has access to anything in that directory tree (that's the recursive change) with the rwx permissions being unchanged from the previous group-owner.
Owning your WordPress files
Remember superbob‘s file ownership?
He's the file's user, allowing him to read and edit it. The web server is the group-owner with read-only rights, allowing Apache to work with WordPress. Shared types, meanwhile, are both user and group file owner to isolate the risk of one user manipulating the common server to hack another user's account. Now, Apache runs under the permissions of the shared hosting user.
Putting all that into practise
Good idea. Best way to learn. Play with the commands, ideally on a sandbox server or, failing that, in a new test folder tree (which you should delete thereafter). Only then will you see that the theory, really truly, sounds far more complex than is the practise. And praise be for that!