Permissions and sudo

Table of Contents

1. Who Can Do What
2. Reading Permissions in ls -l
3. What r, w, and x Mean for Files and Folders
4. Changing Permissions: chmod
5. Number Permissions: 755, 644, 600
6. Running Your Own Scripts: Why ./ and +x
7. Becoming Administrator: sudo
8. When Not to Use sudo
9. Try It Yourself

1. Who Can Do What

In Files and File Systems you saw that every file on macOS and Linux has an owner and a set of permissions, and that Permission denied is the operating system enforcing them. This chapter is where you learn to read those permissions and change them.

Why does this matter if you're the only person using your laptop?

• Your computer has many "users" you never see. System services, databases, and web servers each run as their own user, so a bug in one can't touch the files of another.
• Servers are shared. When you deploy an app to a Linux server, the app, the web server, and you are all different users, and getting permissions right is part of keeping it secure.
• Scripts need permission to run. You'll hit this in this very chapter.

cd ~/cli-practice

Git Bash: Windows stores permissions differently, so chmod has little effect there and sudo doesn't exist. Read along anyway — you'll need all of this on servers and in Docker containers — and use WSL if you want to try every exercise.

2. Reading Permissions in ls -l

Back in chapter 3, you skipped part of the ls -l output. Let's read it now:

ls -l notes/shopping.txt

-rw-r--r--  1 dara  staff  29 Oct  1 10:15 notes/shopping.txt

The first block, -rw-r--r--, is ten characters. The first one is the type (- for a file, d for a folder). The other nine are three groups of three:

 -    rw-     r--     r--
type  owner   group   others

• owner (also called user, u) — the user who owns the file: dara
• group (g) — a group of users who share access: staff
• others (o) — everyone else on the computer

In each group, the three positions are always r, w, x, in that order. A letter means the permission is granted; a - means it isn't. So -rw-r--r-- reads as: "a file; the owner can read and write it; the group can only read it; everyone else can only read it."

That's the most common permission for an ordinary file.

On macOS you may see an extra @ or + right after the permissions, like -rw-r--r--@. That just means the file has extra metadata attached. You can ignore it.

3. What r, w, and x Mean for Files and Folders

The letters mean slightly different things for files and folders:

Two of these surprise people:

• Deleting a file depends on the folder, not the file. Removing a file changes the folder's list of contents, so it's the folder's w that matters.
• Folders need x to be used at all. Without it, you can't cd into the folder or open anything inside, even if you know the names. That's why folders almost always have x wherever they have r: drwxr-xr-x.

4. Changing Permissions: chmod

chmod (change mode) changes permissions. The easiest way to use it is with letters: who, then + (add) or - (remove), then which permission:

chmod u+x file      # owner: add execute
chmod g-w file      # group: remove write
chmod o-r file      # others: remove read
chmod go-rw file    # group and others: remove read and write
chmod +x file       # add execute for everyone

Let's see it in action. Make a file and take away your own permission to read it:

echo "top secret" > notes/secret.txt
chmod u-r notes/secret.txt
cat notes/secret.txt

cat: notes/secret.txt: Permission denied

You own the file, but you've told the OS not to let even you read it. Give it back:

chmod u+r notes/secret.txt
cat notes/secret.txt

You can only change permissions on files you own (or as administrator, in section 7).

5. Number Permissions: 755, 644, 600

In tutorials and documentation, you'll often see permissions written as three digits, like chmod 755 or chmod 600. Each digit is one group — owner, group, others — and is made by adding up:

So 7 = 4 + 2 + 1 = rwx, 6 = 4 + 2 = rw-, 5 = 4 + 1 = r-x, 4 = r--, and 0 = ---.

You'll meet the same few combinations again and again:

chmod 600 notes/secret.txt
ls -l notes/secret.txt

-rw-------  1 dara  staff  11 Oct  1 11:02 notes/secret.txt

Now only you can read or write it. SSH will actually refuse to use a private key that other users can read — one of the first permission errors you'll meet when deploying to a server.

Never chmod 777. It means "everyone can read, change, and run this". Tutorials sometimes suggest it to make a Permission denied error go away, and it does — by removing all protection. Figure out who needs access instead.

6. Running Your Own Scripts: Why ./ and +x

A shell script is a text file full of commands. Let's make a tiny one (chapter 11 explains the first line):

printf '%s\n' '#!/bin/bash' 'echo "Hello from my first script!"' > hello.sh

Try to run it the way you'd run any command:

hello.sh

zsh: command not found: hello.sh

Remember chapter 9: the shell only looks for commands in the folders on your PATH, and the current folder isn't one of them. That's deliberate — otherwise a malicious file named ls sitting in a downloaded folder could run instead of the real ls. To run a program in the current folder, give its path: ./ means "in this folder" (chapter 3).

./hello.sh

zsh: permission denied: ./hello.sh

Progress, but now the OS refuses. Look at the permissions:

ls -l hello.sh

-rw-r--r--  1 dara  staff  47 Oct  1 11:10 hello.sh

There's no x anywhere. A new file is never executable by default — another safety feature. Add it:

chmod +x hello.sh
./hello.sh

Hello from my first script!

Both pieces were needed: ./ so the shell can find it, and +x so the OS will run it. This is exactly the Permission denied error from chapter 2.

You can also skip the x permission by passing the file to Bash yourself, since Bash only needs to read it:

bash hello.sh

7. Becoming Administrator: sudo

Some files belong to the system, not to you. Try writing into the system folder /etc:

touch /etc/test-file

touch: /etc/test-file: Permission denied

These files are owned by root, the administrator user, who can do anything on the system. When you genuinely need to change something system-wide — most often, installing software — you use sudo (superuser do) to run one command as root:

sudo apt update             # Ubuntu and WSL: refresh the list of packages
sudo apt install tree       # install a program called tree

sudo asks for your own password (not a separate root password — on WSL, it's the Linux password you chose during setup), and just like when you set up WSL, nothing appears on screen as you type. It remembers for a few minutes, so the next sudo won't ask again.

On macOS, you'll rarely need sudo for installing software: the Homebrew package manager (brew install tree) is designed to work without it.

Try the new program:

tree ~/cli-practice

It draws your practice folder as a tree — like the diagram in Files and File Systems.

If you ever see a prompt ending in # instead of $, you are logged in as root (chapter 1). Every command runs with full power, so be extra careful — and type exit when you're done.

8. When Not to Use sudo

sudo turns off the safety rails, so the rule is: use it only when you know why a command needs root. "I got Permission denied, so I added sudo" is a habit that causes real problems:

• Never use sudo inside your own projects. If sudo npm install or sudo git pull creates files in your project, those files are now owned by root, and your normal user gets Permission denied on them forever after.
• Don't sudo npm install -g. Installing global Node.js tools with sudo is a classic source of permission headaches. Use a Node version manager like nvm, which installs everything inside your home folder so sudo is never needed.
• Never sudo a command you copied but don't understand. rm -rf with sudo can delete the operating system itself.

If you've already ended up with root-owned files inside your home folder, chown (change owner) gives them back to you:

sudo chown -R $USER ~/cli-practice

-R means recursive — the folder and everything inside it — and $USER is your username (chapter 9). This is one of the rare cases where sudo is the right tool: only root can change who owns a file.

9. Try It Yourself

Work inside ~/cli-practice.

1. Run ls -l in notes and ls -ld notes (the -d shows the folder itself, not its contents). Read the permissions out loud: who can do what?
2. Create notes/private.txt, then use chmod with letters to remove all permissions for group and others. Check with ls -l.
3. Do the same thing to a second file using a number. Which number did you use?
4. Create a folder locked, run chmod 000 locked, and try ls locked and cd locked. Then restore it with chmod 755 locked.
5. Create your own script greet.sh that runs echo and date. Try to run it with greet.sh, then ./greet.sh, then fix it with chmod +x and run it successfully.
6. On Ubuntu or WSL, install tree with sudo apt install tree (or brew install tree on macOS with Homebrew) and run tree on your practice folder.

You now know why Permission denied happens and how to fix it the right way. In the final chapter, let's put everything together and write a real shell script.