Users, Groups, and File Permissions

Users, Groups, and File Permissions in Linux

Linux is a multi-user operating system, meaning many people can log in and work on the same machine at the same time. To keep one user's files safe from another — and to protect system files from accidental or malicious changes — Linux uses a permission model built around three concepts: users, groups, and permission bits. Understanding this model is essential for every web and software developer who deploys code on a Linux server.

Users and Groups

Every file and directory on a Linux system is owned by exactly one user (the owner) and exactly one group. When you create a file, Linux assigns your username as the owner and your primary group as the group.

System administrators create new users with `useradd` and set passwords with `passwd`. Users are collected into groups with `groupadd` and `usermod`. For example:

```bash

sudo groupadd webteam

sudo useradd -m -G webteam alice

sudo useradd -m -G webteam bob

```

This creates a group called `webteam` and two users, alice and bob, who belong to it. The `-G` flag adds each user to the `webteam` group without changing their primary group.

To change the owner or group of an existing file or directory, use `chown`:

```bash

sudo chown alice:webteam /var/www/webteam

```

This sets the owner to alice and the group to webteam.

Reading Permission Bits

Run `ls -l` and you will see output like this:

```

-rwxr-x--- 1 alice webteam 4096 Jun 1 10:00 deploy.sh

```

The first ten characters are the permission string. The first character indicates the file type (`-` for regular file, `d` for directory, `l` for symbolic link). The next nine characters are three groups of three:

| Position | Who | Bits |

|----------|-----|------|

| 2-4 | Owner (user) | rwx |

| 5-7 | Group | r-x |

| 8-10 | Others (world) | --- |

Each position can hold `r` (read), `w` (write), or `x` (execute), or `-` if that permission is not set.

Symbolic and Octal Notation

`chmod` changes permission bits. You can write permissions two ways.

Symbolic notation uses letters and operators:

```bash

chmod g+w file.txt # add write for group

chmod o-rwx config.php # remove all permissions for others

chmod u=rw,g=r,o= data.csv # set exact permissions

```

Octal notation expresses each group of three bits as a single digit (0–7). Read = 4, write = 2, execute = 1. Add the values together:

| Octal | Binary | Permissions |

|-------|--------|-------------|

| 7 | 111 | rwx |

| 6 | 110 | rw- |

| 5 | 101 | r-x |

| 4 | 100 | r-- |

| 0 | 000 | --- |

Example: `chmod 750 deploy.sh` means owner=rwx (7), group=r-x (5), others=none (0).

The Sticky Bit

On a shared directory, any user with write permission could delete another user's files. The sticky bit prevents this: only the file's owner (or root) can delete it, even if others have write access to the directory. Set it with:

```bash

sudo chmod 1775 /var/www/webteam

sudo chmod +t /var/www/webteam

```

When `ls -l` shows a `t` at the end of the permission string (e.g., `drwxrwxr-t`), the sticky bit is active.

The Least-Privilege Principle

The least-privilege principle means giving every user, process, and file exactly the permissions needed to do its job — and nothing more. Applied to a web project:

• Configuration files (e.g., `config.php` containing database credentials) should be readable only by the web server process user and the owner — never world-readable.
• Data files that are only read by scripts do not need the execute bit.
• The web root should not be world-writable; doing so would let any process on the server overwrite your code.

OWASP (the Open Web Application Security Project) lists insecure file permissions as a common contributing factor to web application compromise. World-writable configuration files are especially dangerous because an attacker who gains any local access can overwrite them.

Safety and Best Practices

While Linux administration does not involve physical electrical hazards in the same way as electrical trades, there are important professional safety habits:

• Never run your web application as root. Create a dedicated service account with minimal rights.
• Test permission changes on a non-production VM first. An incorrect `chmod -R` can break an entire web application.
• Always verify before and after using `ls -l` or `stat`, and record the output in your lab log for accountability.
• Back up configuration files before editing ownership or permissions in case you need to restore.
• Use `sudo` carefully. Elevate privilege only for the specific command that requires it.

Setting a Shared Web Directory

A common pattern for a development team is a shared directory where all team members can read and write files, but each file is protected from deletion by others:

```bash

sudo mkdir -p /var/www/webteam

sudo chown root:webteam /var/www/webteam

sudo chmod 2775 /var/www/webteam # setgid + rwxrwxr-x

```

The setgid bit (the `2` in `2775`) causes new files created inside the directory to inherit the group `webteam` automatically, so all team members can access them without manual `chown` every time.