Saltar a contenido

06 - Permissions and Users

What this session is

About 45 minutes. You'll learn Linux's user system, file permissions, and sudo - the "run as administrator" mechanism.

Users and groups

Linux is multi-user. Every process runs as some user. Every file is owned by a user and a group.

whoami            # your username
id                # full info: UID, GID, group memberships
groups            # groups you belong to

The special user root (UID 0) can do anything - modify any file, kill any process, install software. Most operations should not run as root; you stay logged in as yourself and elevate when needed (via sudo).

File permissions

Every file has three sets of permissions, for three classes: - Owner (the user who owns it). - Group (the group it's assigned to). - Others (everyone else).

Each set has three permissions: - Read (r) - can read the contents. - Write (w) - can modify or delete. - Execute (x) - can run it (for binaries) or cd into it (for directories).

ls -l shows them:

-rwxr-xr-- 1 alice staff 1234 May 17 10:23 script.sh

The first character is the file type (- regular, d directory, l link).

The next 9 characters are permissions in three groups of 3: - rwx (owner) - read, write, execute. - r-x (group) - read, execute, no write. - r-- (others) - read only.

So alice can do anything; members of staff can read and execute but not modify; everyone else can only read.

Octal notation

Each rwx set is a 3-bit number: - r = 4 - w = 2 - x = 1

Sum them per set: rwx = 7, r-x = 5, r-- = 4.

So rwxr-xr-- is 754. You'll see permissions written this way constantly.

Common permission patterns:

Octal Symbolic Use case
755 rwxr-xr-x Executable scripts and binaries
644 rw-r--r-- Regular files (default for new files)
700 rwx------ Private directory or executable
600 rw------- Private file (SSH keys, sensitive data)
777 rwxrwxrwx World-writable - almost always wrong

chmod: change permissions

chmod 644 file.txt              # set octal
chmod +x script.sh              # add execute for everyone
chmod -w file.txt               # remove write for everyone
chmod u+x script.sh             # add execute for owner (u=user) only
chmod g-r file.txt              # remove read for group
chmod o= file.txt               # remove all permissions for others
chmod -R 755 directory/         # recursive

Symbolic form: [ugo][+-=][rwx]. - u user (owner), g group, o others, a all. - + add, - remove, = set exactly. - r, w, x for read/write/execute.

For making a script executable: chmod +x script.sh.

chown: change owner

sudo chown bob file.txt              # change owner to bob
sudo chown bob:staff file.txt        # change owner and group
sudo chown -R bob ~/shared           # recursive

You typically need sudo to change ownership (you can give files away or take them - risky without privilege).

Directories: special meanings

Permissions on directories are slightly different: - r - list contents (ls). - w - create, delete, rename files inside. - x - enter the directory (cd) and access files inside.

You can have x without r: enter the directory, access named files, but not list. (Useful for "private" directories where users know the file name but can't browse.)

sudo: run as root

Most beginner mistakes come from sudo. Use it deliberately.

sudo command           # run command as root (asks for your password the first time)
sudo apt update        # update package lists (needs root)
sudo nano /etc/hosts   # edit a system file

After typing your password, sudo remembers for ~5 minutes by default. Be careful with anything you run as root - there's no protection from yourself.

sudo -i or sudo su - gives you a root shell. Useful for many root commands in a row; risky because you're a typo away from disaster. Avoid unless necessary.

Common patterns

Make a script executable:

chmod +x ~/bin/myscript.sh

Lock down an SSH private key (required by SSH):

chmod 600 ~/.ssh/id_rsa

Recursively fix permissions in a directory:

chmod -R 755 mydir       # directories rwxr-xr-x, files rwxr-xr-x
# Often you actually want:
find mydir -type d -exec chmod 755 {} \;     # dirs rwxr-xr-x
find mydir -type f -exec chmod 644 {} \;     # files rw-r--r--

That handles the "dirs need execute but files probably don't" case.

A real example: read a system file

Try:

cat /etc/shadow

You'll get Permission denied. That file stores password hashes; only root can read it.

sudo cat /etc/shadow

Now it works. Don't actually do this in normal life - but it demonstrates the privilege system.

Going deeper

The basics get you through daily file work. This is the depth that turns "Permission denied" from a wall into a diagnosis - the failure modes you'll hit, with exactly what you'll see and what to check.

The "Permission denied" decision tree

When something is denied, the cause is one of a few specific things, and the fix differs for each. Read the actual permissions with ls -l and walk the tree:

$ ls -l deploy.sh
-rw-r--r-- 1 alice devs 412 May 23 deploy.sh
 ^^^^^^^^^^   ^^^^^ ^^^^
 permissions  owner group
  • "Permission denied" running a script (./deploy.sh) -> it's not executable. The x bit is missing (-rw-r--r-- has no x). Fix: chmod +x deploy.sh. This is the #1 beginner stumble - you wrote a script, but a file isn't runnable until you say so.
  • "Permission denied" reading a file -> you're not the owner, not in the group, and "others" can't read it. Check which of the three you are (whoami, groups) against the three permission triads. Fix: sudo if it's legitimately root-only, or chmod/chown if you should own it.
  • "Permission denied" writing to a file you can read -> you have r but not w. Common with config files owned by root.
  • "Permission denied" entering a directory (cd somedir fails) -> the directory lacks the x bit for you. On directories, x means "can enter/traverse," not "execute" - a subtle but crucial distinction (next section).

The discipline: ls -l first, always. Don't guess at the cause or reflexively sudo - read the permissions, identify which triad applies to you, and apply the targeted fix.

Directory permissions mean something different (the gotcha)

On a file, r/w/x mean read/write/execute. On a directory they mean something else entirely, and this trips up everyone:

  • r on a directory = you can list its contents (ls).
  • w on a directory = you can create and delete files in it - note: deleting a file needs write on the directory, not the file! You can delete a file you can't even write to, if you own the directory.
  • x on a directory = you can enter/traverse it (cd, or access files inside by path).

The classic confusion this explains:

$ ls -ld mydir
d---x--x--x  ...                  # x but no r
$ cat mydir/secret.txt            # WORKS - you can traverse (x) and read the file
hello
$ ls mydir                        # FAILS - you can't list (no r)
ls: cannot open directory 'mydir': Permission denied

A directory with x but no r lets you access files if you know their names but not list them - a real technique for semi-private directories. And the reverse (r but no x) lets you see filenames but not access them. Knowing file-perms != dir-perms resolves a whole category of "why can I read the file but not list the folder?" mysteries.

The special bits people never learn (but hit)

Beyond rwx, three special permission bits show up in real systems and look alarming if you don't know them:

$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root ...        # the 's' where 'x' should be = setuid
$ ls -ld /tmp
drwxrwxrwt ...                    # the 't' at the end = sticky bit
  • setuid (s in owner's x slot) - the program runs as its owner, not as you. passwd is setuid-root so a normal user can change their password (which requires writing the root-owned /etc/shadow). It's why a non-root user can run a tool that does privileged things. Also a security-sensitive bit - a setuid-root program with a bug is a privilege-escalation hole, which is why auditors hunt for unexpected setuid files: find / -perm -4000 2>/dev/null.
  • sticky bit (t on a directory) - in a world-writable directory like /tmp, the sticky bit means you can only delete your own files, even though everyone can write there. Without it, anyone could delete anyone's files in /tmp. Now you know what the t in drwxrwxrwt protects.

What you'll see: the umask (why new files have the perms they do)

Ever wonder why a file you create is -rw-r--r-- and not something else? The umask subtracts permissions from new files. Check yours:

$ umask
0022
$ touch newfile && ls -l newfile
-rw-r--r-- ...                     # 666 (default file) minus 022 = 644 (rw-r--r--)

The umask 022 strips write from group and others, which is why your new files are owner-writable but world-readable. If your team needs group-writable files by default (a shared project dir), umask 002 is the fix. Understanding umask explains the otherwise-magic default permissions on everything you create.

Try it (with what you'll see)

  1. Write a script, try ./script.sh -> "Permission denied". ls -l it (no x), chmod +x, run again -> works. Feel the executable-bit gate.
  2. Make a directory chmod 711 mydir (x but no r). Put a file in it. Confirm you can cat mydir/file but ls mydir fails. The file-vs-directory permission distinction, felt.
  3. find /usr/bin -perm -4000 - list the setuid programs on your system. Recognize passwd, sudo, ping. These are the legitimately-privileged tools.
  4. umask, then touch a, check its perms. Change umask 077, touch b, check - b is now owner-only (-rw-------). Watch the umask shape new-file permissions.

Exercise

  1. Create a script:

    cd ~/practice
    echo '#!/bin/bash' > greet.sh
    echo 'echo "Hello, $(whoami)!"' >> greet.sh
    ls -l greet.sh
    
    Note the permissions - probably -rw-r--r--. Not executable yet.

  2. Try to run it:

    ./greet.sh
    
    Permission denied - because no execute bit.

  3. Make it executable:

    chmod +x greet.sh
    ls -l greet.sh
    
    Now -rwxr-xr-x. Try running again:
    ./greet.sh
    
    Should print Hello, <your username>!.

  4. Change to owner-only execute:

    chmod 700 greet.sh
    ls -l greet.sh
    
    Now -rwx------. Still works for you; nobody else can read or run.

  5. Try sudo: read a root-only file:

    sudo cat /etc/shadow | head -n 3       # first 3 lines
    
    Type your password. Read the structure (username:password-hash:other-fields).

  6. Don't do this: sudo rm -rf / would wipe your system. We're not running this. The point: sudo is a sharp tool.

What you might wonder

"Why three classes (user, group, others)?" Historical Unix design: a user, a team, everyone else. Modern systems sometimes use ACLs (setfacl / getfacl) for finer control. The 3-class system is enough for 95% of cases.

"What's the setuid bit (s)?" A 4th permission bit that makes a binary run with its owner's permissions instead of the caller's. Used by passwd (changes /etc/shadow, owned by root). Recognize when you see it; don't set it without care - security risk.

"What's umask?" The default permissions stripped from newly created files. umask 022 (typical) means new files get 666 - 022 = 644 (rw-r--r--). You rarely need to change this.

"How do I share files with someone else?" Add them to a group, set the group on the file (chown :groupname file), give group read/write (chmod 664 file). For collaboration directories, the setgid bit (chmod g+s dir) makes new files inherit the directory's group. Beyond beginner; mentioned for awareness.

Done

  • Read ls -l permissions.
  • Use octal (755) and symbolic (u+x) chmod.
  • Distinguish user, group, others.
  • Use chown to change ownership.
  • Use sudo deliberately.

Next: Pipes and redirection →

Comments