Linux Permissions

Why Permissions Matter

Linux is a multi-user operating system, so it needs a clear way to control who can read, modify, or execute files. Permissions protect configuration files, system binaries, scripts, secrets, and shared directories.

For DevOps engineers, permission mistakes are common sources of deployment failures and security issues.

User, Group, and Other

Every file and directory has an owner and a group. Permissions are evaluated for three categories:

• user: the file owner
• group: users in the file’s group
• other: everyone else

You can see this with ls -l.

ls -l deploy.sh
-rwxr-x--- 1 devops web 842 Jul 14 10:00 deploy.sh

In this example:

• owner = devops
• group = web
• permissions = rwxr-x---

Understanding rwx Notation

Each permission triplet contains up to three letters:

• r = read
• w = write
• x = execute

For files:

• read allows viewing contents
• write allows changing contents
• execute allows running the file as a program or script

For directories:

• read allows listing names
• write allows creating or deleting entries
• execute allows entering the directory and accessing items inside it

A permission string like rwxr-xr-- means:

• user: read, write, execute
• group: read, execute
• other: read only

Octal Notation

Permissions are often represented with numbers:

• r = 4
• w = 2
• x = 1

Add them together for each category:

• 7 = rwx
• 6 = rw-
• 5 = r-x
• 4 = r--

So:

chmod 755 script.sh

means:

• user = 7 = rwx
• group = 5 = r-x
• other = 5 = r-x

Changing Modes with chmod

chmod changes permissions.

Numeric form:

chmod 644 config.yaml
chmod 755 deploy.sh

Symbolic form:

chmod u+x deploy.sh
chmod g-w shared.txt
chmod o-r secret.txt

Examples:

• u+x adds execute for the owner
• g-w removes write from the group
• o-r removes read from others

Tip: Scripts often need chmod +x script.sh before they can be run directly.

Changing Ownership with chown and chgrp

Use chown to change owner and optionally group.

sudo chown devops deploy.sh
sudo chown devops:web /var/www/app

Use chgrp to change only the group.

sudo chgrp web /var/www/app

Ownership matters because even perfect permission bits will not help if the wrong user owns the file.

Special Permission Bits

Linux also supports three special bits.

setuid

When setuid is set on an executable file, the program runs with the file owner’s privileges.

chmod 4755 /path/to/program

This is powerful and should be used carefully.

setgid

On an executable file, setgid runs the program with the file group’s privileges. On a directory, new files created inside inherit the directory’s group.

chmod 2775 shared-dir

This is useful for team-shared directories.

Sticky Bit

The sticky bit on a directory means users can delete only files they own, even if the directory is otherwise writable.

chmod 1777 shared-temp

A classic example is a shared temporary directory.

Note: The sticky bit improves safety in shared writeable directories by preventing users from deleting each other’s files.

Understanding umask

umask controls the default permissions assigned to newly created files and directories.

umask
umask 022

A common umask value is 022, which results in:

• files typically created as 644
• directories typically created as 755

This means the owner can write, but group and others get read-only access by default.

Real-World Scenarios

A Script Will Not Run

You try:

./deploy.sh

but get “Permission denied.” Check and fix:

ls -l deploy.sh
chmod +x deploy.sh

A Web App Cannot Read a Config File

The service runs as www-data, but the file is owned by another user and unreadable to the group. Fixing ownership or permission bits may solve the issue.

sudo chown root:www-data /etc/myapp/config.yaml
sudo chmod 640 /etc/myapp/config.yaml

That allows the owner and group to read while blocking everyone else.

Test Your Understanding

Exercise 1: Choosing a restrictive file mode

Scenario: A service group needs read access to config.yaml, but everyone else should be blocked.

Question: Which permission mode from the lesson best matches that goal for a regular file?

Exercise 2: Using setgid on directories

Question: What is the benefit of setting the setgid bit on a shared directory such as a team project folder?

Exercise 3: Predicting umask results

Question: If the umask is 022, what default file mode does the tutorial say you will usually see?

---

Key takeaways

• Three classes, three bits. User, group and other, each with read, write and execute.
• On a directory the bits mean something different: x is the right to enter it, and r only lists names.
• chmod 755 for directories and executables, 644 for ordinary files covers almost everything.
• Use symbolic mode for changes (chmod u+x) and numeric mode for setting an exact state.
• chmod -R 777 is never the fix. It makes every file world-writable and hides the real problem.
• setuid runs a file as its owner: the reason passwd works for unprivileged users, and a real risk elsewhere.
• The sticky bit on /tmp is what stops users deleting each other's files in a shared directory.

---

Frequently Asked Questions

What does chmod 755 mean?

Each digit is one class, user, group, other, and each is the sum of read (4), write (2) and execute (1). So 755 is rwxr-xr-x: the owner can read, write and execute; group and other can read and execute but not write. It is the standard mode for directories and for executable scripts. The other number you need is 644 (rw-r--r--), the standard for ordinary files, which is 755 without the execute bits.

What is the difference between chmod and chown?

chmod changes permissions. What the owner, group and everyone else are allowed to do. chown changes ownership, which user and group those permissions apply to. They solve different halves of the same problem, and picking the wrong one is a common source of frustration: if a service cannot write to its data directory, the fix is usually chown to the service's user rather than loosening the mode with chmod.

Why do permissions mean something different on a directory?

Because a directory is a list of names, not content. Read (r) lets you list what is inside; write (w) lets you create, rename and delete entries, which is why you can delete a file you cannot write to, as long as you can write to its directory. Execute (x) is the right to traverse the directory, to reach anything inside it. A directory with r but no x lets you see the file names and access none of them, which produces confusing "permission denied" errors on paths that clearly exist.

Is chmod 777 ever the right answer?

Effectively never. It makes a file readable, writable and executable by every account on the system, so any compromised process can rewrite it, and if it is a script something privileged runs, that is a direct path to privilege escalation. It is also usually treating the symptom: the real question is which user needs the access, answered with chown or by adding that user to the right group. The one defensible use is a deliberately shared scratch directory, and then it needs the sticky bit as well.

What are setuid, setgid and the sticky bit?

Three extra bits beyond rwx. setuid (chmod u+s) makes an executable run as its owner rather than the user invoking it. How /usr/bin/passwd can edit /etc/shadow on your behalf, and dangerous on anything else. setgid on a directory makes new files inherit the directory's group, which is the clean way to share a folder between team members. The sticky bit (chmod +t) on a world-writable directory restricts deletion to each file's owner, which is why /tmp is safe to share.

How do umask and default permissions work?

umask is a mask of bits to remove from the defaults when a file is created: 666 for files and 777 for directories. The common default of 022 therefore yields 644 for files and 755 for directories. Set a stricter 077 and new files are readable only by you, which suits a multi-user server. Check the current value with umask and set it in ~/.bashrc for a user or /etc/profile for everyone; note that it affects only newly created files, not existing ones.