Lesson 4: Processes, Users & Permissions — The Core of Linux Security & Execution

1️⃣ Why This Topic Matters (Production Context)

Every time software runs on Linux — whether it’s Nginx, PostgreSQL, Kubernetes components, Docker containers, or CI agents — it runs as:

A process → running as a specific user → accessing resources with permissions

Most real production issues labeled as “app failures” are really:

  • permission problems
  • ownership problems
  • process identity problems
  • security enforcement problems
  • kernel resource policy problems

Example failures caused by misunderstanding this lesson:

❌ Nginx can’t read TLS certificates (wrong permissions)
❌ Kafka can’t write to data directories (wrong ownership)
❌ Docker container can’t bind to port <1024 (requires root)
❌ Systemd kills background jobs (wrong service unit config)
❌ SSH login fails due to incorrect home directory permissions

If you work in:

  • DevOps
  • SRE
  • Platform
  • Cloud
  • Linux Administration
  • Security

…you must understand the relationship between users → processes → permissions.

2️⃣ Core Concepts (Explained Simply)

✔ Concept 1: Processes

A process is:

  • a running program
  • with its own memory
  • scheduled by the kernel
  • identified by a PID (Process ID)

Example:

$ ps -p $$ -o pid,ppid,user,cmd
  PID  PPID USER     CMD
 2831  2771 basha    -bash

✔ Concept 2: Users

Linux has 3 main categories of users:

TypeExamplePurpose
SuperuserrootFull control
System usersnginx, mysql, redisRun services safely
Human usersbasha, devopsInteract via shells/SSH

Users are defined in:

/etc/passwd

✔ Concept 3: Permissions

Permissions define what actions are allowed:

  • r = read
  • w = write
  • x = execute

And apply to:

LevelMeaning
user (u)owner of file
group (g)group members
others (o)everyone else

Example:

-rwxr-x---

✔ Concept 4: Ownership

Two kinds:

  • user ownership (UID)
  • group ownership (GID)

Example:

-rw-r----- 1 nginx webteam  /etc/nginx/conf.d/default.conf

Means:

  • Owned by nginx
  • Group webteam can read
  • Others blocked

✔ Concept 5: Kernel Enforcement

When a process runs:

  1. User performs action (via a process)
  2. Process requests access via system call
  3. Kernel checks permissions
  4. Access granted or denied

If denied:

Permission denied

3️⃣ Commands (With Real Output Examples)

⭐ Inspect Processes

$ ps aux | head
USER   PID %CPU %MEM  COMMAND
root     1  0.1  0.2  /sbin/init
mysql 1279  4.3  4.5  mysqld
nginx 2034  0.0  0.1  nginx: worker

⭐ Inspect Users

$ cat /etc/passwd | head
root:x:0:0:root:/root:/bin/bash
nginx:x:997:996:Nginx user:/var/cache/nginx:/sbin/nologin

Field breakdown:

user:passwd:UID:GID:comment:home:shell

⭐ Inspect Groups

$ cat /etc/group | grep docker
docker:x:999:basha

⭐ Inspect Permissions

$ ls -l /etc/ssl/private
-r-------- 1 root root cert.key

Meaning:

  • Only root can read private key

⭐ Change Ownership

sudo chown nginx:nginx /var/www/html

⭐ Change Permissions

chmod 640 config.yaml

⭐ Check Effective User of Process

$ ps -o user,group,pid,cmd -p <pid>

4️⃣ Real DevOps / SRE Scenarios

Scenario A: Nginx TLS Key Permission Failure

Symptom:

nginx: [emerg] cannot load certificate key "/etc/ssl/private/key.pem"

Cause:

-r-------- 1 root root key.pem

Fix:

  • Either allow group read:
chown root:nginx key.pem
chmod 640 key.pem
  • OR use ssl_certificate_key in correct path

Scenario B: Docker Port Binding

Binding to port <1024 requires root:

docker run -p 80:80 nginx

Kubernetes uses nodeport >30000 to avoid this.

Scenario C: Log Write Failures

App fails with:

Permission denied: /var/log/myapp/

Debug:

ls -ld /var/log/myapp
ps -o user= -p $(pgrep myapp)

Solution: adjust chown/chmod for log directory.

Scenario D: Sudo Without Environment

A common beginner issue:

sudo systemctl restart myapp

works but:

sudo myapp

fails because it lacks environment variables.

Understanding shells + users + permissions prevents these mistakes.

5️⃣ Common Mistakes Engineers Make

❌ Running everything as root
❌ Using chmod 777 as a bandaid
❌ Forgetting which user systemd runs as
❌ Assuming containers run as same user as host
❌ Placing TLS keys in world-readable directories
❌ Using shared user accounts for automation
❌ Confusing file owner vs process owner

Each leads to outages or security incidents.

6️⃣ Intermediate & Advanced Notes (For Mid-Level Engineers)

🧠 System Call Pipeline

When a user opens a file:

  1. Process issues open() syscall
  2. Kernel checks permission bits
  3. LSM hooks apply (SELinux/AppArmor/seccomp)
  4. VFS layer handles mapping to actual filesystem

🧠 Capabilities

Linux breaks root into capability bits:

CAP_NET_BIND_SERVICE
CAP_SYS_ADMIN
CAP_CHOWN
CAP_NET_ADMIN

Docker & Kubernetes use these to avoid full root.

🧠 Namespaces & Cgroups (Containerization)

Containers rely on:

  • user namespaces → UID isolation
  • mount namespaces → filesystem view
  • pid namespaces → process tree isolation
  • cgroups → resource enforcement

This is why container users are often remapped.

🧠 SELinux/AppArmor

Adds Mandatory Access Control (MAC) beyond chmod/chown.

Example SELinux denial:

permission denied (13): AVC message=denied { read }

7️⃣ Practical Takeaways (Checklist)

✔ Every process runs as a user
✔ Permissions control file access
✔ Group ownership is powerful for service sharing
✔ Kernel enforces access via syscalls
✔ Never use chmod 777 in production
✔ TLS keys should not be world-readable
✔ System users exist for security isolation
✔ Containers add namespaces + capabilities on top

Scroll to Top