Linux Permissions

For additonal context to set up your workspace, please view the first guide in this series: User and Group Management in Linux.

Every file, directory, and other system objects in Linux are assigned an owner and a group. This is the most basic, yet essential, part of system security that protects users from each other. Owners, users belonging to a group, and all others may be granted different types of access to read from, write to, or execute files. This is generally referred to as file permissions in Linux.

To set permissions and manage ownership, we will use the following commands:

• chmod: change file permissions

• chown: change file owner

• chgrp: change group ownership

• id: print user and group IDs

Typically, the owner of a file is the user who created it and (at least initially) the group is the one associated with the owner (also known as primary group). To illustrate, let's create a new file called test1 in the current working directory:

Then let's do ls -l on it:

The first character in the output indicates that test1 is a regular file (i.e. not a directory or other type of system object). The next nine characters (divided in 3 groups of 3) indicate the read (r), write (w), and execute (x) permissions of the owner, the group owner, and the other users in the system.

The first group of 3 characters (rw-) indicate that the owner of the file (user pluralsight) has read and write permissions, as it is the case with the group (as indicated by the next 3 characters). Finally, the last group (r--) means that the rest of the users can only read that file - but not write to it or execute it.

The read permission on a file is necessary for it to be opened and read. The same permission on a directory (along with execute) is required to list its contents and to move into it.

To change the permissions on a file, we will use chmod. This command must be followed by a symbolic representation that indicateswho the new permissions should be applied to:

• u means user (or more precisely, the owner of the file)
• g means group
• o means all other users
• a means all users

The type of permission:

• +r adds read permission
• -r removes read permission
• +w adds write permission
• -w removes write permission
• +x adds execute permission
• -x removes execute permission
• +rw adds read and write permissions
• +rwx adds read and write and execute permissions

and so on.

Finally, we also need to indicate the name of the file or directory. Let's change the permissions on test1 as follows. To begin, we will add execute permissions for the owner only:

Next, we will do

to remove read and write permissions from users other than the owner and not in the group owner.

Let's take a look at the current permissions of test1 after making the above changes:

Another way to set permissions is using an octal instead of a symbolic expression. To translate into octal form, we must split the desired permissions in groups of 3 characters and use the following table to replace each group with its octal equivalent:

Each permission is often referred to as bit based on the above table. Thus, the presence of a given permission means the corresponding bit is set. For example, r-x means that both the read and execute bits are set, whereas the write bit is not. Thus, if you need to assign rwx permissions on test1 for the owner, rw for the group, and only r for everyone else, you should do

In the above command, the 7, 6, and 4 represent rwx, rw, and r, respectively.

Other examples:

• rw permissions for the owner and the group and no access whatsoever for other users: chmod 660 test1

• All (rwx) permissions for the owner but only read and execute permissions for everyone else (this includes both the group and other users): chmod 755 test1

When to use the symbolic expression or the octal form to set permissions depends on the specific scenario. If only a bit needs to be set, it's likely that the symbolic expression will be faster. But if we want to set different permissions for the owner, the group, and all others, the octal form is easier and more straightforward.

If we executed the above commands, the current permissions of test1 are rwxr-xr-x (755) and both the owner and the group are pluralsight and pluralsight, respectively.

Let's now introduce the use of chgrp to change the group owner of test1 to finances. The command must be followed by the group name and the name of the file whose ownership needs to be set (test1 in this case).

Next, let's see if user student can write to this file. As we can see in the following image, we get a Permission denied error. To give student write access to the file, we can set the corresponding bit for the group:

and then add the account to finances, again using usermod but this time with the -aG combined option as follows:

The -aG combined option is short for append to group.

Now finances are said to be a secondary or supplementary group for user student. The new access permissions will take effect the next time student logs in.

At that point, we can use

to verify that the account was added correctly to the group. If we're logged in as student, doing just id will do the trick.

If instead of adding student to the finances group, we wanted to make him the owner of test1, we can use chown followed by the user and file names, in that order:

Note that the above command will cause pluralsight to not have access to test1 anymore, as such account is now neither the owner of the file or been added to the finances group.

Besides the standard rwx file permissions, there are three others that are worth mentioning: setuid, setgid, and the sticky bit. Let's examine each of them.

• When the setuid bit is set on an executable file, any user can execute it using the permissions of the owner of such file.

• When the setgid bit is set on an executable file, any user can execute it using the permissions of the group of such file.

These special permissions pose a security risk when used carelessly. For example, if any user is allowed to run a command with superuser privileges, he or she can gain access to files owned by other users and even by root. It isn't hard to see how this can easily cause havoc in a system: essential files could be removed, personal directories could be wiped out entirely, and even hardware can experience erratic behavior. It only takes a malicious or irresponsible individual to cause all this. Thus, the use of the setuid and the setgid bits must be highly restricted.

A valid case where the setuid bit must be used is in /usr/bin/passwd. This file is owned by root but needs to be used by any user to change his or her own password (but not that of other users).

• When the sticky bit is set on a directory, the files within that directory can be deleted only by the owner, the owner of the directory, or by root. This is often used in shared directories to prevent a user from deleting other people's files from it.

To set the setuid bit on test1:

To set the setgid:

To create a directory named files and set the sticky bit on it:

To illustrate the use of these special permissions, let's take a look at the following image. Note how now there is a t where the execute permission should be for all users in files and two s's in the same position for the owner and the group.

Under this scenario and, if test1 was a program, any user could execute it using the permissions of pluralsight (owner) or the access privileges of the finances group.

Using /etc/sudoers, we can also allow all the users in a group to execute programs with superuser privileges. For example, the following line indicates that members of finances are allowed to run updatedb (or more precisely, /usr/bin/updatedb):

The only difference when compared to individual users is that the group name must be prefaced by the % sign. Command aliases can be used in this case as well.

To list the allowed commands for the invoking user in /etc/sudoers, simply do sudo -l in the command line and press Enter.

Please continue on to the next guide in this series: Linux Processes - Part 1 to continue learning about Linux Administration.