Users, Groups & Permissions

Understanding Users and Groups

Linux is a multi-user system. Each user has a unique UID, and users can belong to multiple groups for access control.

$ whoami
pranav

$ id
uid=1000(pranav) gid=1000(pranav) groups=1000(pranav),27(sudo),docker

$ groups
pranav sudo docker

File Permissions

Every file has three permission types for three user classes:

Permission	Symbol	Numeric	Description
Read	r	4	View file contents / list directory
Write	w	2	Modify file / create files in directory
Execute	x	1	Run file as program / enter directory

$ ls -l script.sh
-rwxr-xr-- 1 pranav developers 1024 Dec 18 10:00 script.sh
│└┬┘└┬┘└┬┘
│ │ │ └── Others: read only (r--)
│ │ └───── Group: read + execute (r-x)
│ └──────── Owner: read + write + execute (rwx)
└────────── File type (- = regular file)

Changing Permissions

# Symbolic mode
$ chmod u+x script.sh # Add execute for owner
$ chmod g-w file.txt # Remove write for group
$ chmod o=r file.txt # Set others to read only

# Numeric mode
$ chmod 755 script.sh # rwxr-xr-x
$ chmod 644 file.txt # rw-r--r--

Ownership: user + group

Permissions only make sense together with ownership. Every file has an owner (user) and a group. Ownership decides which permission triplet applies.

$ ls -l /var/log/syslog
-rw-r----- 1 root adm ... /var/log/syslog

# Change owner and group
$ sudo chown pranav:developers project.txt
$ sudo chgrp developers project.txt

Creating and Managing Users

On servers, you’ll often create service accounts, lock interactive login, and grant limited sudo. Key files include /etc/passwd (public user info) and /etc/shadow (password hashes; root-only).

# Create user + home directory
$ sudo useradd -m -s /bin/bash deploy
$ sudo passwd deploy

# Add to a group (e.g., sudo)
$ sudo usermod -aG sudo deploy

# Create a group
$ sudo groupadd developers
$ sudo usermod -aG developers deploy

Sudo: controlled privilege escalation

Instead of sharing root passwords, Linux uses sudo to allow specific users (or groups) to run privileged commands. The main config is /etc/sudoers and drop-in files in /etc/sudoers.d/.

# Always edit sudoers using visudo
$ sudo visudo

# Check what you can run
$ sudo -l

Security note

Prefer granting sudo via a group and limit commands where possible. Avoid NOPASSWD: ALL on shared systems.

Special Permission Bits (setuid, setgid, sticky)

These bits change how permissions behave and are common on multi-user systems.

•setuid: run a binary with the file owner’s privileges (often root). Example: passwd.
•setgid: run with the file group, or on directories, force new files to inherit the directory group.
•sticky bit: on shared directories (like /tmp), users can only delete their own files.

$ ls -ld /tmp
drwxrwxrwt 10 root root ... /tmp
# Notice the trailing 't' (sticky bit)

umask and Defaults

umask controls default permissions for new files/directories. It’s a safety net to avoid accidentally creating world-writable content.

$ umask
0022

# 0022 typically means new files: 644 and directories: 755

ACLs (Fine-Grained Permissions)

Standard permissions are coarse. ACLs let you grant access to specific users/groups without changing ownership. Useful for shared directories in teams.

$ getfacl shared.txt
$ setfacl -m u:deploy:rw shared.txt
$ getfacl shared.txt | sed -n '1,12p'

✅ Practice (15 minutes)

Create a directory and set setgid on it so new files inherit the group.
Use sudo -l to understand your sudo permissions.
Create a file and use setfacl to grant read access to another user (or test with your own user + a group).