Right, let’s get into the guts of file permissions. You’ve probably seen the cryptic rwxrwxr-x and wondered, “Is this a license plate or a security system?” It’s a bit of both. At its core, it’s a brilliantly simple, if occasionally infuriating, way to control who can do what to your files. We’re going to crack it open.

The first thing to wrap your head around is that these three little letters mean something completely different depending on whether they’re on a file or a directory. This is the single biggest source of confusion, so we’ll tackle it head-on.

The rwx Trio for Files

For a regular file, it’s pretty straightforward:

  • Read (r): You can view the contents of the file. Think cat, less, more. If you don’t have read permission, these commands will slap you with a Permission denied error. The file is a sealed envelope.
  • Write (w): You can modify the contents of the file. This lets you save changes with a text editor, truncate it, or append to it. But here’s the fun part: write permission on a file does not let you delete the file itself. That power lies elsewhere (we’ll get to that).
  • Execute (x): The file can be run as a program or script. This could be a binary like /bin/bash or a script that has a shebang (e.g., #!/bin/bash) at the top. Without this bit set, trying to run it will result in a Permission denied error, even if you can read every byte of it. The system is saying, “I see the recipe, but you’re not allowed to start cooking.”

Let’s see this in action. Let’s create a file and play with its permissions.

$ echo "echo 'Hello, wise user.'" > my_script.sh
$ ls -l my_script.sh
-rw-r--r-- 1 user user 24 Oct 26 14:30 my_script.sh  # Read & Write for user, Read for everyone else.
$ ./my_script.sh
bash: ./my_script.sh: Permission denied # No execute bit!

$ chmod u+x my_script.sh  # Give the user (owner) execute permission
$ ls -l my_script.sh
-rwxr--r-- 1 user user 24 Oct 26 14:30 my_script.sh  # Note the 'x' for the user now
$ ./my_script.sh
Hello, wise user.

The rwx Trio for Directories

This is where people’s brains short-circuit. Directories are just special files that contain a list of their contents (filenames and links to inodes). The permissions govern access to that list, not the files within it directly.

  • Read (r): You can list the contents of the directory. Commands like ls require this permission. Without it, ls will fail, even if you know a specific file exists inside.
  • Write (w): This is a big one. Write permission on a directory allows you to change the directory’s content list. This means you can create new files, delete existing files, or rename files regardless of the individual file’s permissions. Yes, you read that right. If you have write permission on a directory, you can delete a file you don’t even own and that has its permissions set to 000. This is the “elsewhere” I mentioned. The directory is the gatekeeper; controlling the gate gives you power over everything behind it.
  • Execute (x): This is sneakily renamed the “search” permission for directories. You need it to do anything inside the directory. You can’t cd into it, you can’t access any file within it (even if you know its full path), and you can’t get metadata about files inside it with ls -l. The execute bit is the key that unlocks the door to the directory itself.

Let’s create a playground to see this madness in action.

$ mkdir test_dircd test_dir
$ echo "secret stuff" > important_file.txt
$ chmod 000 important_file.txt  # Remove all permissions from the file
$ ls -l important_file.txt
---------- 1 user user 13 Oct 26 14:35 important_file.txt # Permissions are gone

# Now, let's change the directory's permissions
$ chmod 755 ../test_dir  # user: rwx, group/other: r-x (the common safe setting)
$ ls -l ../test_dir/
ls: cannot access '../test_dir/important_file.txt': Permission denied
# The directory is readable, so we see *something* is there, but we can't access it due to the file's perms.

$ chmod 733 ../test_dir  # user: rwx, group/other: -wx (write & execute, but NOT read)
$ ls ../test_dir/
ls: cannot open directory '../test_dir/': Permission denied # Can't list contents (no 'r')

# But we know the file is there. Let's try to access it directly and even delete it.
$ cat ../test_dir/important_file.txt
cat: ../test_dir/important_file.txt: Permission denied # File has no read, so we can't.

$ rm ../test_dir/important_file.txt
rm: remove write-protected regular file '../test_dir/important_file.txt'? y
$ ls -la ../test_dir/  # Let's see if it's gone... oh wait, we can't 'ls' it.
ls: cannot open directory '../test_dir/': Permission denied

$ echo "new file" > ../test_dir/new_file.txt  # But we can create a new one!
$ cat ../test_dir/new_file.txt # And we can read the new one we created.
new file

See? The directory’s w bit let us delete and create files, completely bypassing the individual file’s permissions. This is why securing a system is about more than just locking down files—you have to lock down the directories that contain them. The most common pitfall is leaving a world-writable directory lying around (chmod o+w /some/path). It’s an invitation for anyone to come in and delete your stuff or fill your disk with their junk. Don’t do it.