Skip to content

Cookie settings

Choose which kinds of cookies you allow. You can change your choice at any time via Cookie settings at the bottom of every page. Privacy statement

Necessary

Always on

Needed to log in, keep your cart and remember your choices. These are always on.

Which cookies?
  • weboke_sessie, weboke_klant, weboke_remember: your session and staying logged in
  • weboke_basket: your cart
  • wkBtwIncl: showing prices with or without VAT
  • wok_cookies: your cookie choice, 12 months

Measures which ad leads to a visit or order, so we do not pay for ads that do nothing.

Which cookies?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), up to 90 days
  • OpenAI Ads, ads in ChatGPT
  • wok_aff: which partner referred you to us (affiliate programme), 60 days

4.6

Country and language

Each country has its own site, with prices and VAT for that country.

View

Module 3 · 3.1

Users, groups and file permissions

Module 3: Users, permissions and sudo · Reading time: 12 minutes

Learning objective: After this lesson you can create and inspect users and groups, read the permissions of a file or directory in ls -l, and set them correctly with chmod and chown without throwing everything wide open.

Key concepts: root (UID 0), regular user, system user, /etc/passwd, /etc/shadow, group, adduser, id, rwx, owner, group, others, octal (644, 755, 600), chmod, chown, umask, setuid, 777

Everyone is a number

Linux was built from the start for multiple users on one machine. Every running process runs on behalf of a user, and every file has an owner. To the system, a user is mainly a number, the UID:

  • root has UID 0. Root can do anything: read and change any file, stop any service, create any user. There is no "are you sure?".
  • Regular users, such as anna, get a UID from 1000 upwards on Debian and Ubuntu. They can write in their own home directory and not much else.
  • System users have a low number and usually no password and no shell. Services run as one of these users: nginx as www-data, PostgreSQL as postgres. If such a service is hacked, the intruder only gets the permissions of that user, not those of root.

You can see who you are with id:

anna@web1:~$ id
uid=1000(anna) gid=1000(anna) groups=1000(anna),27(sudo),100(users)

Anna has UID 1000, her own group anna, and is also a member of the groups sudo and users.

Where users are stored

The list of users is in /etc/passwd, one line per user:

anna@web1:~$ grep -E '^(root|www-data|anna):' /etc/passwd
root:x:0:0:root:/root:/bin/bash
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
anna:x:1000:1000:Anna,,,:/home/anna:/bin/bash

The fields, separated by colons, are: name, x (the password is stored elsewhere), UID, primary group, description, home directory and shell. For www-data the shell is /usr/sbin/nologin: logging in is not possible.

The passwords themselves are stored encrypted (hashed) in /etc/shadow. Only root can read that file. A ! or * at the start of the password field means you cannot log in with a password. That is how root is locked by default on Ubuntu, and on Debian if you did not set a root password during installation.

Creating users and groups

On Debian and Ubuntu you use the friendly adduser:

root@web1:~# adduser anna
info: Adding user `anna' ...
info: Adding new group `anna' (1000) ...
info: Adding new user `anna' (1000) with group `anna (1000)' ...
info: Creating home directory `/home/anna' ...
info: Copying files from `/etc/skel' ...
New password:
Retype new password:
...

adduser creates the user, a personal group with the same name and a home directory, and asks for a password. The lower-level useradd also exists (and is the usual command on AlmaLinux and Rocky Linux), but without options it does less: no password, and on some systems no home directory.

A group is a way to give permissions to several users at once. To add a user to a group:

root@web1:~# adduser anna www-data
root@web1:~# usermod -aG www-data anna     # same thing, works everywhere

Watch out for the -a in usermod: without -a you replace all of the user's extra groups with just this one. A new group only takes effect after logging in again.

To lock an account without deleting it (for example one belonging to a former colleague):

root@web1:~# usermod -L -e 1 jan

-L locks the password and -e 1 expires the account. Note: a locked password does not always stop an SSH key. So also remove the keys in /home/jan/.ssh/authorized_keys (lesson 2.3); sshd does refuse the expired account (-e 1).

Reading permissions

anna@web1:~$ ls -l /var/www/example.com
total 12
-rw-r--r-- 1 anna     www-data  1520 Nov  9 10:12 index.html
-rw-r----- 1 anna     www-data   412 Nov  9 10:14 config.php
drwxr-xr-x 2 anna     www-data  4096 Nov  9 10:15 images
drwxrwxr-x 2 www-data www-data  4096 Nov  9 10:20 uploads

The first block of ten characters is the key to everything:

  • Character 1: the type. - is a regular file, d a directory, l a shortcut (symlink).
  • Characters 2 to 4: what the owner may do.
  • Characters 5 to 7: what the group may do.
  • Characters 8 to 10: what others (everyone else) may do.

After that come the number of links, the owner, the group, the size and the date.

For a file, the letters mean:

LetterMeaning for a file
rread
wchange
xrun as a program or script

And for a directory something slightly different:

LetterMeaning for a directory
rlist the names of the files in the directory
wcreate, rename and delete files in the directory
xenter the directory and open files in it

That last one surprises a lot of people. Without x on a directory you cannot get to the files inside, even if they are readable themselves. And anyone with w on a directory can delete files in it, even if they belong to someone else.

In the example: anyone may read index.html; config.php (with the database password) can be read and changed by Anna, only read by the group www-data (so the web server), and the rest get nothing. The web server may write in uploads, because that is where visitors' uploads go.

Permissions as a number

Permissions are often written as three digits, the octal number. Each letter has a value: r = 4, w = 2, x = 1. Add them up per group:

PermissionsNumberUse
rw-r--r--644regular file that anyone may read
rw-r-----640file for owner and group, such as a configuration with a password
rw-------600secret file, such as authorized_keys or a private key
rwxr-xr-x755directory or program that anyone may use
rwx------700private directory, such as ~/.ssh

Changing permissions: chmod and chown

anna@web1:~$ chmod 640 /var/www/example.com/config.php
anna@web1:~$ chmod g+w /var/www/example.com/uploads
root@web1:~# chown anna:www-data /var/www/example.com/config.php

chmod changes the permissions, using a number or letters (u, g, o for owner, group, others; + or - and the letter). chown eigenaar:groep changes the owner and group; only root may do that. With -R both work on an entire directory, and that is where things often go wrong: chmod -R 644 on a directory makes all subdirectories unusable, because directories need x. For a whole tree, use find instead:

root@web1:~# find /var/www/example.com -type d -exec chmod 755 {} +
root@web1:~# find /var/www/example.com -type f -exec chmod 644 {} +

Never 777

"It didn't work, so I just set it to 777." 777 means: everyone on the server may read, change and run this. If a single service or website on your server is ever compromised, the intruder can write anywhere 777 is set, including your PHP files. The real problem is almost always the owner or the group: give the web server exactly the permission it needs through the group, and only on the directory where it is needed.

Default permissions and special bits

New files get their permissions through the umask. With the usual umask 022, new files become 644 and new directories 755. You can see your umask with the command umask.

Sometimes you see an s instead of an x, as with /usr/bin/passwd (-rwsr-xr-x). That is the setuid bit: the program runs with the permissions of its owner (root), even when a regular user starts it. A few system programs need this, but never set it on a script yourself. An unexpected setuid file is a well-known sign of a break-in; find / -perm -4000 -type f 2>/dev/null shows you all of them.

On AlmaLinux and Rocky Linux

There, adduser is another name for useradd; use useradd -m anna and then passwd anna. You add groups with usermod -aG. SELinux adds an extra layer on top of the permissions in this lesson: a file with the right permissions can still be refused if it has the wrong SELinux label (ls -Z shows it).

Summary

  • Every user has a UID; root (0) can do anything, and services run as their own system users without a shell.
  • Users are stored in /etc/passwd, the password hashes in /etc/shadow. Create users with adduser and add groups with usermod -aG.
  • ls -l shows the type, the permissions of owner, group and others, and then the owner and group. For a directory, x means enter and w means create and delete files.
  • Common numbers: 644 and 755 for public, 640 for configuration with secrets, 600 and 700 for private. Never 777.
  • Use find to set permissions on a whole tree; keep an eye on setuid files.

Quiz

1. What does -rw-r----- mean for a file with owner anna and group www-data?



2. What happens if a directory has the permissions drw-r--r-- (so no x anywhere)?



3. You run usermod -G www-data anna (without -a). What is the result?



4. A plugin cannot write to /var/www/example.com/uploads. What is the best solution?



5. Why does nginx run as the user www-data and not as root?



Exercise

Exercise Z3.1: Reading permissions. Open the sample file rechten-1.txt: the output of id for three users and of ls -l in a web directory. For each question, answer who may do what (for example: "can the web server change config.php?", "which file has permissions that are too broad?", "which number matches .env?"). The program compares your answers with the fixed answer key and explains the reasoning for each question.

Exercise Z3.1: Reading permissions

File for this exercise: rechten-1.txt










What you enter and what we find isn't stored. Your browser remembers your answers and whether you've passed the exercise. If you're signed in, we only save that you got the exercise (almost) right in My courses; you can delete that there too.

Further reading

The steps in these articles apply to WebOké's hosting packages and VPSs; other providers work in a similar way.

One moment…

Set up your domains

For each domain, arrange the nameservers, the link to your hosting and who becomes the owner.

Loading your domains…