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.
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:
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:
Lock down an SSH private key (required by SSH):
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:
You'll get Permission denied. That file stores password hashes; only root can read it.
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. Thexbit is missing (-rw-r--r--has nox). 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:sudoif it's legitimately root-only, orchmod/chownif you should own it. - "Permission denied" writing to a file you can read -> you have
rbut notw. Common with config files owned by root. - "Permission denied" entering a directory (
cd somedirfails) -> the directory lacks thexbit for you. On directories,xmeans "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:
ron a directory = you can list its contents (ls).won 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.xon 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 (
sin owner'sxslot) - the program runs as its owner, not as you.passwdis 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 (
ton 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 thetindrwxrwxrwtprotects.
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)¶
- Write a script, try
./script.sh-> "Permission denied".ls -lit (nox),chmod +x, run again -> works. Feel the executable-bit gate. - Make a directory
chmod 711 mydir(x but no r). Put a file in it. Confirm you cancat mydir/filebutls mydirfails. The file-vs-directory permission distinction, felt. find /usr/bin -perm -4000- list the setuid programs on your system. Recognizepasswd,sudo,ping. These are the legitimately-privileged tools.umask, thentouch a, check its perms. Changeumask 077,touch b, check -bis now owner-only (-rw-------). Watch the umask shape new-file permissions.
Exercise¶
-
Create a script:
Note the permissions - probablycd ~/practice echo '#!/bin/bash' > greet.sh echo 'echo "Hello, $(whoami)!"' >> greet.sh ls -l greet.sh-rw-r--r--. Not executable yet. -
Try to run it:
Permission denied- because no execute bit. -
Make it executable:
Now-rwxr-xr-x. Try running again: Should printHello, <your username>!. -
Change to owner-only execute:
Now-rwx------. Still works for you; nobody else can read or run. -
Try sudo: read a root-only file:
Type your password. Read the structure (username:password-hash:other-fields). -
Don't do this:
sudo rm -rf /would wipe your system. We're not running this. The point:sudois 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 -lpermissions. - Use octal (
755) and symbolic (u+x) chmod. - Distinguish user, group, others.
- Use
chownto change ownership. - Use
sudodeliberately.