Linux Permissions

Understand Linux ownership, rwx permissions, octal notation, chmod, chown, special bits, and umask.

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

Let's see how well you understood the concepts! These exercises will help reinforce what you just learned.

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

Exercise 1: Choosing a restrictive file mode

Pick the mode that gives the owner read and write, the group read, and others no access.

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

Exercise 2: Using setgid on directories

Identify what setgid changes for new files created inside a shared directory.

Exercise 3: Predicting umask results

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

Exercise

Exercise 3: Predicting umask results

Choose the typical default permission for newly created files when umask is 022.

Continue Learning

Explore Related Topics

Try the Tool

Related Resources