Users, Permissions and sudo

Linux was designed from the start as a multi-user system, and its permission model is one of the most important security concepts you will learn. Who owns this file? Who may read it, change it, run it? Why does a web server run as a special account rather than as an administrator? In this lesson you learn to read and set permissions, to understand the administrator account, and to use sudo responsibly.

In the previous lesson you moved around the file system and probably met a few "permission denied" messages. Now we find out why they appear, and what they protect.

Users and groups

Every process and every file on a Linux system belongs to a user, and to a group. A user is identified by a name and a numeric UID. The administrator, called root, has the UID 0 and can do anything. Many other accounts are service accounts, created to run a particular program with limited rights, for example a web server or a database. Most of them cannot be used to log in.

Groups gather users who share rights. A user has one primary group and may belong to several others. Useful commands:

whoami          # current user name
id              # UID, GID and groups of the current user
groups          # groups of the current user
who             # who is logged in
last -n 5       # recent logins

The accounts of the system are listed in /etc/passwd (readable by everyone, despite the name it contains no passwords nowadays), and the password hashes are stored in /etc/shadow, which only root can read. That separation is a security measure: the hashes that you will study in chapter 6 must not be visible to everyone. Groups are defined in /etc/group.

Look at one line of /etc/passwd:

student:x:1000:1000:Student,,,:/home/student:/bin/bash

The fields are: user name, a placeholder for the password (the x means "look in shadow"), UID, primary GID, a comment, the home directory and the login shell. Service accounts often have a shell such as /usr/sbin/nologin, which prevents interactive login. An audit habit worth acquiring: check which accounts have a real shell and whether each one is expected.

Reading permissions

Run ls -l on a directory. Each line starts with ten characters:

-rw-r--r-- 1 student student  220 Jan  5 10:00 notes.txt
drwxr-xr-x 2 student student 4096 Jan  5 10:01 lab
-rwxr-x--- 1 root    admins   512 Jan  5 10:02 backup.sh

The first character is the type: - for a regular file, d for a directory, l for a symbolic link. The next nine characters are three triplets, for three categories of people:

1. The owner (user) of the file.
2. The group of the file.
3. Others, meaning everyone else.

Each triplet shows three permissions: r (read), w (write) and x (execute), or a dash when the permission is absent. For a directory, r means you can list its content, w means you can create or delete entries in it, and x means you can enter it and access what it contains.

So -rw-r--r-- means: a regular file where the owner can read and write, the group can only read and others can only read. And -rwxr-x--- means the owner can do everything, the group can read and execute, and others have no access at all.

Changing permissions: chmod and chown

chmod changes permissions. You can use letters or numbers. The number form assigns a value to each permission: read is 4, write is 2, execute is 1, and you add them per triplet:

chmod 640 notes.txt        # owner rw-, group r--, others ---
chmod 755 script.sh        # owner rwx, group r-x, others r-x
chmod u+x script.sh        # add execute for the owner
chmod o-r notes.txt        # remove read from others
chown student:admins notes.txt   # change owner and group (needs root)

The principle behind the numbers is again least privilege: give each file the minimum rights it needs. A private note should not be readable by others (600). A file with credentials must never be world-readable. A frequent beginner's mistake is running chmod 777 to "make the error go away": it gives everyone full control, and it is a classic cause of security problems on real servers.

Special permissions to recognise

Three special bits exist, and you should at least know that they exist and why they matter for security:

• setuid (shown as an s in the owner's execute position): a program with this bit runs with the rights of its owner, not of the person who launched it. It is how a normal user can change their own password (the passwd program needs to write in protected files). A badly written setuid program owned by root is a classic route to privilege escalation, so auditors list them.
• setgid: similar, for the group; on a directory, new files inherit the group of the directory.
• sticky bit (shown as a t at the end, as on /tmp): in a shared directory, users can delete only their own files.

You can list setuid files on your own lab machine to see what is there:

find / -perm -4000 -type f 2>/dev/null

Knowing the normal list of your system is the starting point for noticing something unusual.

The administrator and sudo

Working as root all the time is dangerous: a single typo or a single malicious program can wreck the system. Modern practice is to log in as a normal user and to use sudo ("superuser do") to run a specific command with administrator rights, only when needed.

sudo apt update
sudo cat /etc/shadow
sudo -l

The user is asked for their own password, the command runs with root rights, and the action is recorded in a log. The command sudo -l lists what you are allowed to run. Who may use sudo, and for which commands, is defined in the /etc/sudoers file, which must be edited with the dedicated visudo command that checks the syntax (a broken sudoers file can lock you out). Members of a group named sudo (on Debian-based systems) typically have full rights.

Why is this better than sharing the root password? Because sudo gives accountability (each action is tied to a person and a time), the ability to grant limited rights (only some commands), and avoids staying in an all-powerful session. Misconfigured sudo rules are, however, a classic source of privilege escalation: allowing a user to run a text editor or a scripting interpreter as root effectively gives them a root shell. When you design rules, think of what each allowed command can actually do.

Managing accounts

The administrator creates and manages accounts with commands such as:

sudo adduser analyst           # create a user (interactive)
sudo usermod -aG sudo analyst  # add to the sudo group (careful!)
sudo passwd analyst            # set a password
sudo deluser analyst           # remove a user

Note the -a in usermod -aG: without it, the command replaces all existing group memberships instead of adding one, a common and painful mistake. Good account hygiene includes removing accounts that are no longer needed, using strong, unique passwords or keys, and not sharing accounts.

Your turn: a small permissions exercise

On your Linux server VM, create a user guest1 (without sudo rights). As your normal user, create a file ~/lab/secret.txt containing a line of text. Set permissions so that only you can read and write it. Check using ls -l. Then switch to the other user with su - guest1 (you will need its password) and try to read the file. What happens? Then, back as your user, change the permission to give read access to others, and try again as guest1. Finally, explain what you must also check on the parent directory.

sudo adduser guest1
echo "lab secret" > ~/lab/secret.txt
chmod 600 ~/lab/secret.txt
ls -l ~/lab/secret.txt
su - guest1
cat /home/yourname/lab/secret.txt