Industry Leader in Digital Business

Howto: Managing your webserver using a CLI (part 2: rights management)

In my previous post, Howto: Managing your webserver using a CLI (part 1: the basics), you learned how to establish a connection to server over SSH. In addition the basic commands for file management were given and explained using various examples. One of the most important aspects of file management on Linux servers was however not discussed: rights management. In this article you will first learn how the rights management on Linux servers is build up, after which the commands to modify these rights are given and explained.

Users and user groups

Linux has a powerful, yet somewhat complex system for rights management (compared to for example Windows) that needs some explanation. Within Linux, every file has an owner and a user group assigned to it. The owner of the file is a (virtual) user that owns the file: it can make changes to the rights of the file and thus modify all aspects of the file. The owners and other users can be grouped in one or multiple user groups which allows administrator to easily manage the rights of multiple users. For example, on most servers there is a virtual user that started the webserver and has an obvious name like ‘apache’. Also, there is usually at least one other user that can login using the ftp to change the files on the server. Now, if we would only be able to give one user access to a file, then either the webserver or the user could use the file, but not both. By putting both users in an user group (for example ‘www-data’), an administrator can make sure that both users can access, modify or remove the file while still keeping the file protected from other users that are not part of this user group. The image below shows how this would work in practice:

Rights management

Rights management

Now that we are aware of the fact that a file can have both a user and user group assigned to it, we can start reviewing the rights permissions for the files on the server. The command ls -l (or ls -al to include hidden files), which was discussed in the previous article, allows us to see who has the rights to read, write or execute files on the system. Take for example the following list of files:

{code}user@SYcommerce-Server ~ $ ls -l
total 18
drwxrwxr-x 3 user www-data 4096 Feb 2 18:09 classes
drwxrwxr-x 5 user www-data 24 Feb 2 18:10 images
drwxrwxr-x 3 user www-data 72 Feb 2 18:10 includes
-rwxrwxr-x 1 user www-data 2047 Feb 2 18:13 index.php
-rwxrwxr-x 1 user www-data 35147 Feb 2 18:13 license.txt
-rw——- 1 user www-data 280 Feb 2 18:13 robots.txt
drwxrwxr-x 4 user www-data 16 Feb 2 18:13 templates
user@SYcommerce-Server ~ $>{/code}

For rights management the first, third and fourth columns are most interesting: they give information on the assigned rights (first column), the owner of the file (third column) and the user group assigned to the file (fourth column). As you can see ‘user’ is currently owner of the file, while the file has been placed in the user group ‘www-data’ to allow user ‘apache’ to have access as well (review the previous section for clarification if necessary). The first column tell us what kind of rights the assigned user, user group and other users have for the files listed. The string in this column contains 10 characters, starting with either a ‘d’ for directory or ‘-‘ for a file. The remaining nine characters can be split up by in three parts each giving rights to a certain group or user. In the above example the grouping of the 9 characters ‘rwxrwxr-x’ would thus be split into: rwx (the owners’ rights), rwx (the user groups’ rights) and r-x (the global rights, thus everone). This tells us that both the owner and the users in the assigned user group can read (r), write (w) and execute (x) the listed files, except for ‘robots’txt’. Furthermore, all other users can read and execute most files in this directory, but they cannot modify them as they have no rights to write to the file. As mentioned, there is one file that is only readable and writable by the owner as the rest of the permissions have been withdrawn: robots.txt.

Changing owners and user groups of files/directories

In the example above, the file ‘robots.txt’ was only usable by ‘user’ and not by the user group. From this, we have learned that the user of the webserver (‘apache’) cannot read or write to the file, though we know that it should have access. One way to solve this problem is to make ‘apache’ owner of the file, giving it all the privileges (thus read and write) that the current owner currently has. To do so, the command chown must be used with the new owner, user group and file or directory name as parameters. In the example below we make the necessary change to allow apache access to the file:

{code}user@SYcommerce-Server ~ $ chown apache:www-data robots.txt
user@SYcommerce-Server ~ $ ls -l
total 18
drwxrwxr-x 3 user www-data 4096 Feb 2 18:09 classes
drwxrwxr-x 5 user www-data 24 Feb 2 18:10 images
drwxrwxr-x 3 user www-data 72 Feb 2 18:10 includes
-rwxrwxr-x 1 user www-data 2047 Feb 2 18:13 index.php
-rwxrwxr-x 1 user www-data 35147 Feb 2 18:13 license.txt
-rw——- 1 apache www-data 280 Feb 2 18:13 robots.txt
drwxrwxr-x 4 user www-data 16 Feb 2 18:13 templates
user@SYcommerce-Server ~ ${/code}

Changing rights of files/directories

Modifying the user rights is somewhat more diffecult as the command for this (chmod) requires an octal value to indicate the read, write and execute permission for the owner, user group and global scope. The octal value can be calculated for each group by taking the three characters for each group (see the section ‘Rights Management’) and calculate the cumulative value for this group of characters using the following values: r=4, w=2 and x=1. Two examples for rwx (all permissions) and r-x (read and execute) will most likey make this more clear.

{code} r w x
0 + 4 + 2 + 1 = 7

r – x
0 + 4 + 0 + 1 = 5{/code}

So, if we want to change a file in a way that the owner and user group have all permission, but the other users can only read and execute the file, we would combine our calculations:

{code}rwx (user) + rwx (group) + r-x (other)
7 7 5{/code}

Like with chown, the command chmod expects a filename and the new settings for the rights. As an example, the command below changes the permissions for ‘robots.txt’ so that both ‘apache’ and ‘user’ both have access to the file, solving our problem entirely. In addition we give global users read and execute access, but not write permission (as this would mean that everyone can change the contents of the file):

{code}user@SYcommerce-Server ~ $ chmod 775 robots.txt
user@SYcommerce-Server ~ $ ls -l
total 18
drwxrwxr-x 3 user www-data 4096 Feb 2 18:09 classes
drwxrwxr-x 5 user www-data 24 Feb 2 18:10 images
drwxrwxr-x 3 user www-data 72 Feb 2 18:10 includes
-rwxrwxr-x 1 user www-data 2047 Feb 2 18:13 index.php
-rwxrwxr-x 1 user www-data 35147 Feb 2 18:13 license.txt
-rwxrwxr-x 1 apache www-data 280 Feb 2 18:13 robots.txt
drwxrwxr-x 4 user www-data 16 Feb 2 18:13 templates
user@SYcommerce-Server ~ ${/code}

Rights management for multiple files

Of course it is not practical to manage the rights per file and thus you can you use the wildcards * and ? which were explained in the previous article in this series. There is also an additional option that is worth mentioning. By default, only the files and directories in the current directory will be modified by chown and chmod which means that you have to set the permissions in the subdirectories manually. The parameter -R, which stands for ‘recursion’, can be used to include subdirectories in the process. The full command for changing the rights of all files in the current directory and all subdirectories would thus be chmod -R 775 *. With commands like these you should now be able to make your webserver more secure and reliable, as only users that require permission to write to a file should have this permission. Also keep in mind: if you are unsure about the rights management on your server, it is always better to contact your hosting provider or drastically restrict the permissions than to possibly keep the gates wide open for everyone on the server.

Related Posts