Linux Administration Lesson 6 – File Permissions and Ownership | Dataplexa
Section I — Linux Fundamentals

File Permissions and Ownership

In this lesson

The permission model Reading permission strings chmod — symbolic and octal chown and chgrp Special bits — SUID, SGID, sticky

File permissions are the mechanism Linux uses to control which users and processes can read, write, or execute each file and directory on the system. Every file has an owner, a group, and a set of permission bits that determine access for three categories of users. Misconfigured permissions are one of the most common causes of both security vulnerabilities and broken applications on Linux servers.

The Unix Permission Model

Linux inherits the Unix permission model. Every file and directory has exactly one owner (a user) and one group. Permissions are defined separately for three categories — the owner, the group, and everyone else (called "others" or "world").

- r w - r - - r - - 1 alice devs 4096 File Type - file d dir l link Owner (u) rw- = read+write Group (g) r-- = read only Others (o) r-- = read only Owner / Group alice devs Full string: -rw-r--r-- 1 alice devs 4096 Mar 10 script.sh

Fig 1 — Anatomy of a permission string from ls -l

r — Read (4)

On a file: view its contents. On a directory: list its contents with ls.

w — Write (2)

On a file: modify its contents. On a directory: create, rename, or delete files inside it.

x — Execute (1)

On a file: run it as a program. On a directory: enter it with cd and access its contents.

— No Permission (0)

A dash - in place of a letter means that permission is not granted for that category.

Analogy: Permissions are like a building access card system. The owner has their own card. The group shares a card for a department. Everyone else either gets in or doesn't. The security desk (kernel) checks the card on every entry attempt.

Octal Notation

Each permission bit has a numeric value: r=4, w=2, x=1. Adding these values together for each category produces a three-digit octal number that represents the full permission set. This is the most efficient way to set permissions with chmod.

OWNER (u) GROUP (g) OTHERS (o) r 4 w 2 - 0 4+2+0 = 6 r 4 - 0 - 0 4+0+0 = 4 r 4 - 0 - 0 4+0+0 = 4 Result: chmod 644 — rw-r--r-- (owner read/write, group and others read-only)

Fig 2 — Calculating octal permission values for 644

Common Permission Values
Octal String Typical Use
600 rw------- Private files — SSH private keys, credentials
644 rw-r--r-- Standard config files, web content
664 rw-rw-r-- Shared files for a team group
755 rwxr-xr-x Executable scripts, public directories
700 rwx------ Private executable — only owner can run
777 rwxrwxrwx Full access for everyone — avoid on production

chmod — Changing Permissions

The chmod command changes the permissions of a file or directory. It accepts two notations — octal (numeric) and symbolic (letter-based). Octal is faster for setting all permissions at once. Symbolic is clearer when adding or removing a single permission without affecting others.

# ── Octal notation ──────────────────────────────────────
# Set permissions to rw-r--r-- (owner rw, group r, others r)
chmod 644 config.yml

# Make a script executable by owner only
chmod 700 deploy.sh

# Set a directory to rwxr-xr-x
chmod 755 /var/www/html

# Apply recursively to all files under a directory
chmod -R 644 /var/www/html

# ── Symbolic notation ────────────────────────────────────
# Add execute for the owner (u+x)
chmod u+x deploy.sh

# Remove write from group and others
chmod go-w sensitive.conf

# Give everyone read permission
chmod a+r readme.txt

# Set exact permissions symbolically
chmod u=rw,g=r,o=r config.yml
# Before: ls -l deploy.sh
-rw-r--r-- 1 alice devs 512 Mar 10 deploy.sh

# After: chmod u+x deploy.sh
-rwxr--r-- 1 alice devs 512 Mar 10 deploy.sh

# After: chmod 755 deploy.sh
-rwxr-xr-x 1 alice devs 512 Mar 10 deploy.sh

What just happened? The first chmod u+x added the execute bit only for the owner, leaving group and others unchanged. The second chmod 755 set all three categories precisely in one operation — owner gets rwx, group and others get r-x.

chown and chgrp — Changing Ownership

Permissions only make sense when the correct owner and group are assigned. chown changes the owner and optionally the group of a file. chgrp changes only the group. Both require root or sudo to change ownership away from yourself.

# Change owner to www-data
chown www-data /var/www/html/index.html

# Change owner and group together (owner:group)
chown alice:devs /home/alice/project/

# Change owner recursively across an entire directory tree
chown -R nginx:nginx /etc/nginx/

# Change only the group
chgrp developers /opt/app/config.yml

# Verify the change
ls -la /opt/app/config.yml
# -rw-r--r-- 1 alice developers 1024 Mar 10 config.yml
# chown -R nginx:nginx /etc/nginx/
# ls -la /etc/nginx/
drwxr-xr-x  4 nginx nginx 4096 Mar 10 09:14 .
drwxr-xr-x 95 root  root  4096 Mar  8 11:22 ..
drwxr-xr-x  2 nginx nginx 4096 Mar 10 09:14 conf.d
-rw-r--r--  1 nginx nginx 1450 Mar  9 14:03 nginx.conf
drwxr-xr-x  2 nginx nginx 4096 Mar 10 09:14 sites-enabled

What just happened? The chown -R nginx:nginx command recursively changed every file and subdirectory under /etc/nginx/ to be owned by the nginx user and group. The Nginx process, which runs as the nginx user, can now read its own config files.

Special Permission Bits — SUID, SGID, Sticky Bit

Beyond the standard rwx bits, Linux supports three special permission bits that modify how execution and directory access work. These appear infrequently but have significant security implications that every administrator must understand.

SUID

Set User ID — octal 4000, shown as s in owner execute position

When set on an executable file, the process runs with the file owner's privileges rather than the calling user's. The classic example is /usr/bin/passwd — it runs as root so ordinary users can update their own password entry in /etc/shadow.

chmod u+s /usr/bin/myapp # or chmod 4755
SGID

Set Group ID — octal 2000, shown as s in group execute position

On an executable: runs with the file's group privileges. On a directory: new files created inside inherit the directory's group rather than the creator's primary group. This is widely used for shared team directories.

chmod g+s /opt/shared/team # or chmod 2755
Sticky

Sticky Bit — octal 1000, shown as t in others execute position

On a directory: users can only delete or rename their own files, even if they have write access to the directory. The standard example is /tmp — everyone can write there, but no one can delete another user's files.

chmod +t /tmp # or chmod 1777
# Verify SUID on passwd — notice the 's' in owner execute position
ls -l /usr/bin/passwd
# -rwsr-xr-x 1 root root 59976 Jan 15 /usr/bin/passwd

# Verify sticky bit on /tmp — notice the 't' in others execute position
ls -ld /tmp
# drwxrwxrwt 12 root root 4096 Mar 10 /tmp

# Find all SUID files on the system (useful security audit)
find / -perm -4000 -type f 2>/dev/null

umask — Default Permission Control

The umask (user file creation mask) controls the default permissions assigned to newly created files and directories. It works by subtracting its value from the system maximum — 666 for files and 777 for directories.

umask 022 (default)

Files: 666 − 022 = 644 (rw-r--r--)
Directories: 777 − 022 = 755 (rwxr-xr-x)

Standard for most servers — group and others can read but not write.

umask 027 (restrictive)

Files: 666 − 027 = 640 (rw-r-----)
Directories: 777 − 027 = 750 (rwxr-x---)

Common on security-hardened servers — others get no access at all.

# View current umask
umask
# 0022

# View umask in symbolic form
umask -S
# u=rwx,g=rx,o=rx

# Set a more restrictive umask for the current session
umask 027

# Set umask permanently for all users (add to /etc/profile or /etc/bashrc)
echo "umask 027" >> /etc/profile

chmod 777 Is a Security Risk

Setting chmod 777 on any file or directory gives every user on the system full read, write, and execute access. On a web server this means any compromised web process can overwrite configuration files or inject malicious scripts. For scripts, use 755. For config files, use 644. For sensitive credentials, use 600. Never use 777 on production.

Lesson Checklist

I can read a full permission string from ls -l and identify owner, group, and others permissions
I can convert between symbolic permission strings and octal values
I can use chmod with both octal and symbolic notation to set or modify permissions
I can use chown and chgrp to assign correct ownership to files and directories
I can explain the purpose of SUID, SGID, and the sticky bit with a real example of each

Teacher's Note

Permissions are one of the most frequently tested topics in RHCSA and Linux+ certification exams. Practice converting between octal and symbolic notation until it becomes instant — a table of 644, 755, 700, and 600 is worth memorising cold.

Practice Questions

1. A web server's document root at /var/www/html is owned by root and the Nginx process cannot read its files. State the two commands needed to fix this — one to set ownership and one to set permissions — and justify your chosen permission values.

2. Convert the following octal values to their symbolic permission strings and describe who can do what in each case: 640, 750, 600.

3. A shared directory /opt/team is used by multiple users in the devs group. State the two special bits that should be set on this directory, explain the purpose of each, and write the commands to apply them.

Lesson Quiz

1. A file has the permission string rwxr-x---. Its octal value is which of the following?

2. The SUID bit on /usr/bin/passwd allows which of the following?

3. The command chmod go-w file.txt does which of the following?

Up Next

Lesson 7 — Users and Groups Basics

User accounts, group membership, /etc/passwd, /etc/shadow, and the sudo model