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:
echo "This is a dummy file called test1" > test1
Then let's do
ls -l on it:
ls -l test1
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:
The type of permission:
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:
chmod u+x test1
Next, we will do
chmod o-rw test1
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:
ls -l test1
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
chmod 764 test1
In the above command, the 7, 6, and 4 represent rwx, rw, and r, respectively.
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).
sudo chgrp finances test1
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:
sudo chmod g+w test1
and then add the account to finances, again using
usermod but this time with the
-aG combined option as follows:
sudo usermod -aG finances student
-aGcombined 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:
sudo chown student test1
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).
To set the setuid bit on test1:
sudo chmod u+s test1
To set the setgid:
sudo chmod g+s test1
To create a directory named files and set the sticky bit on it:
sudo mkdir files sudo chmod +t files
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):
%finances ALL=(ALL) /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.
Test your skills. Learn something new. Get help. Repeat.Start a FREE 10-day trial