Users and Permissions¶

Overview¶

Linux is a multi-user operating system where access control is fundamental. Every file and process is owned by a user and a group. The permission system (read, write, execute for owner, group, and others) controls who can access what. Special permissions like setuid, setgid, and the sticky bit provide additional control.

System administrators must understand user management (creating users, setting passwords, managing groups), the sudo mechanism (granting limited root access), SSH key-based authentication (passwordless but secure login), and how services run under dedicated user accounts to limit the blast radius of a compromised service.

How It Works¶

Users and Groups¶

Every Linux system has user accounts defined in /etc/passwd and groups defined in /etc/group. Each user has:

A username and numeric UID (User ID)
A primary group and optional supplementary groups
A home directory (typically /home/<username>)
A login shell (e.g. /bin/bash, or /sbin/nologin for service accounts)

Create users with adduser or useradd:

sudo adduser scoring        # Create a new user called 'scoring'
passwd scoring              # Set or change the user's password

Service accounts (like apache, proxy, named) are created with nologin shells so they cannot be used for interactive login. This limits the blast radius if a service is compromised.

File Permissions¶

Every file and directory has three sets of permissions for three classes of user:

Class	Description
Owner (u)	The user who owns the file
Group (g)	The group assigned to the file
Others (o)	Everyone else

Each class can have:

r (read) — view file contents or list directory entries
w (write) — modify the file or create/delete files in a directory
x (execute) — run the file as a program, or traverse (enter) a directory

Permissions are represented in octal notation where r=4, w=2, x=1:

chmod 700 .ssh              # Owner: rwx, Group: ---, Others: ---
chmod 600 .ssh/authorized_keys  # Owner: rw-, Group: ---, Others: ---
chown scoring:scoring .ssh  # Change owner and group

The .ssh directory requires 700 and authorized_keys requires 600 — the SSH daemon will refuse to use them if permissions are too open.

Special Permissions¶

setuid (4xxx): When set on an executable, the process runs with the file owner's privileges rather than the executing user's. Example: /usr/bin/passwd runs as root so normal users can change their own password.
setgid (2xxx): On an executable, the process inherits the file's group. On a directory, new files inherit the directory's group.
Sticky bit (1xxx): On a directory, only the file owner (or root) can delete files within it. /tmp uses the sticky bit.

sudo — Delegated Privilege Escalation¶

sudo allows a permitted user to execute commands as root (or another user) without sharing the root password. Configuration lives in /etc/sudoers, edited safely with visudo:

scoring ALL=(ALL:ALL) NOPASSWD: ALL

This grants the scoring user passwordless sudo access to all commands. The /etc/sudoers.d/ directory allows drop-in configuration files, which is cleaner for automation (e.g. Ansible can create /etc/sudoers.d/scoring without editing the main file).

To test: sudo ls -l /root should succeed without a password prompt.

SSH Key-Based Authentication¶

SSH public-key authentication replaces passwords with a cryptographic key pair:

Private key (~/.ssh/id_rsa) — kept secret on the client machine. Permissions must be 600 or stricter.
Public key (~/.ssh/id_rsa.pub) — placed on the server in ~/.ssh/authorized_keys for each user that should accept this key.

Generate a key pair:

ssh-keygen -t rsa -b 4096

The SSH daemon checks ~/.ssh/authorized_keys for the target user upon login. Multiple keys can be listed (one per line). If the permissions on .ssh/ or authorized_keys are too open, SSH silently falls back to password authentication.

To grant a remote system access (e.g. a scoring server), append its public key to the target user's authorized_keys:

cat id_rsa.pub >> /home/scoring/.ssh/authorized_keys

Key Terminology¶

UID: Numeric user identifier. Root is UID 0. System accounts typically have UIDs below 1000.
GID: Numeric group identifier. Each user has a primary GID; supplementary groups provide additional access.
Octal Permissions: Three-digit numeric representation of file permissions (e.g. 755 = rwxr-xr-x).
setuid / setgid: Special permission bits that cause executables to run with the owner's or group's privileges.
Sticky Bit: Permission bit on directories preventing users from deleting files they do not own.
sudo: A command that allows permitted users to execute commands as another user (typically root).
visudo: The safe editor for /etc/sudoers that validates syntax before saving — a syntax error in sudoers can lock out administrative access.
authorized_keys: A file in ~/.ssh/ listing public keys that are allowed to authenticate as that user via SSH.

Why It Matters¶

Principle of least privilege: Services should run under dedicated accounts with minimal permissions. If a web application is compromised under the apache user, the attacker cannot read /root or modify system files.
Accountability: Individual user accounts (rather than shared root access) create an audit trail of who did what.
Automation: Tools like Ansible need predictable user accounts, SSH key access, and passwordless sudo to manage systems at scale.
Security: Incorrect permissions are one of the most common causes of service failures and security vulnerabilities. SSH is particularly strict about file permissions.

Common Pitfalls¶

Wrong .ssh permissions: SSH silently refuses key authentication if ~/.ssh/ is not 700 or ~/.ssh/authorized_keys is not 600. This is the single most common SSH troubleshooting issue.
Editing /etc/sudoers without visudo: A syntax error in the sudoers file can prevent all sudo access, effectively locking you out of root. Always use visudo or drop files into /etc/sudoers.d/.
Running services as root: Never run application services (web servers, databases, Flask apps) as root. Create dedicated service users with nologin shells.
Forgetting chown after file creation: Files created as root and placed in a user's home directory will be owned by root. The user (or service) may not be able to read them.
Password-only authentication on public-facing SSH: Disabling password authentication and using keys only significantly reduces brute-force attack surface.