File Permissions and Users

Who Can Do What?

Linux is a multi-user system. Every file and every process belongs to a user, and the system constantly asks: is this user allowed to do this? Most privilege-escalation attacks, and most hardening work, come down to getting those answers right.

Reading Permissions with ls -l

-rwxr-x---  1 kali devs  2048 Sep 21 09:14 backup.sh
drwxr-xr-x  2 kali kali  4096 Sep 20 18:02 Documents

The first character is the type (- file, d directory). Then three sets of three: owner, group, others.

So rwxr-x--- means the owner can do everything, the group can read and run, and others get nothing. In numbers that is 750.

chmod and chown

chmod 600 id_rsa          # only the owner can read and write (private key)
chmod 755 script.sh       # owner full, everyone else read and run
chmod u+x,g-w,o-rwx file  # symbolic form: add, remove, set
chown alice:devs report.txt   # change owner and group

Security rules of thumb:

• Private keys and config files with passwords: 600. SSH refuses to use a key that others can read.
• Never use 777. It means anyone on the system can change the file. Attackers search for world-writable files and scripts run by root.
• Give web servers the least access they need. A web app that can write to its own code is a gift to attackers.

Users, Groups and sudo

• root (UID 0) can do anything.
• Normal users get a UID of 1000 or more. Groups let you share access, such as devs or adm.
• sudo lets a permitted user run one command as root. It logs who did what, which is why we use it rather than logging in as root.

id                        # your UID, GID and groups
sudo cat /etc/shadow      # run one command as root

/etc/passwd and /etc/shadow

Two files define local accounts:

/etc/passwd  (readable by everyone)
kali:x:1000:1000:Kali User:/home/kali:/bin/bash
name : password placeholder : UID : GID : comment : home : shell

/etc/shadow  (readable by root only)
kali:$y$j9T$Zx1...:19800:0:99999:7:::
name : password HASH : last change : min : max : warn ...

The x in passwd means "the password hash lives in shadow". Shadow is root-only because password hashes can be attacked offline. If an attacker gets it, tools like John the Ripper or Hashcat can guess weak passwords quickly. A hash beginning $y$ is yescrypt, $6$ is SHA-512, and both are slow by design.

Things to check on a server:

1. Accounts with a shell that should not have one (service accounts should use /usr/sbin/nologin).
2. Any second account with UID 0. That is a hidden root.
3. Users in the sudo group who no longer need it.

A Nigerian and Global Angle

A common real-world finding on servers in Lagos startups and London fintechs alike is a database backup with 644 or 777 permissions sitting in a web-accessible folder. A public web request downloads the whole customer database. Fixing it takes one chmod 600 and a move out of the web root, but only if someone looks.

Try It in the Lab: File Permissions Challenge

You have just joined a Lagos fintech as a junior security engineer, and the checkout server needs fixing. The terminal on the right is a simulated Kali machine where chmod and chown really change files. Complete all five tasks to capture the flag:

1. Read /etc/passwd. One account has UID 0 but is not called root. Who is it, and why is that dangerous?
2. Inspect ~/project with ls -l. Read each permission string out loud: owner, group, others.
3. Make deploy.sh executable for its owner. Try ./deploy.sh before and after.
4. Lock down secrets.env. It is currently rw-rw-rw-. Make it readable and writable by the owner only.
5. Fix ownership of /var/www/html/index.html so the web server user www-data owns it. Notice that only root can do this.

Use the Hint button if you get stuck. Press Reset to put every file back and try again with numeric modes (755, 600) instead of symbolic ones (u+x, go-rw).