# File Management and Permissions

> Chapter 4 of the Courseiva LPI-LPIC1 curriculum — https://courseiva.com/learn/lpi-lpic1/file-management-and-permissions

**Official objective:** 103.3 — Manage file permissions, ownership, and attributes, and use commands like chmod, chown, and umask.

## Introduction

File management and permissions — the system that controls who can read, write, or run every file on a Linux machine. For the LPIC-1 exam, you need to understand how to lock down files so only the right people access them, which is fundamental to keeping any server secure.

## The Apartment Building Lobby Analogy

3 different people live in an apartment building: the building owner, the property manager, and a tenant. The owner (root) can do anything: change locks, demolish walls, or evict everyone. The property manager (a user with sudo privileges) can open any apartment door, but only during business hours. Each tenant (regular user) has their own apartment (home directory) where they control who enters.

File permissions work exactly like the access rules on these 3 units. Each unit (file) has a sign on the door that says: 'The owner (user) can read, write, and execute this file' — meaning they can look inside, change the contents, or run it. The group (like the tenant's family members) might only be allowed to read and execute, but not modify. Everyone else (others) might be locked out completely.

Now imagine the property manager changes the lock on one apartment using a special key — that's chmod. If they want to give the apartment to a different tenant, they use chown. And when a new tenant moves in, they get a default set of permissions — that's the umask value deciding whether the door is wide open, partially open, or completely locked from the start.

## Core explanation

Linux is a multi-user operating system by design. From the moment it boots, multiple processes and potentially multiple human users share the same filesystem. Without permissions, any user could read your private SSH keys, overwrite system configuration files, or run malicious scripts — total chaos. Permissions solve this by assigning an access control list (a set of rules) to every file and directory.

Every file has an owner, which is a user account (like 'alice' or 'root'). It also has a group, which is a collection of users (like 'developers' or 'admins'). Permissions are divided into three sets: one for the owner (user), one for the group, and one for everyone else (others). Each set has three possible permissions: read (r), write (w), and execute (x).

Read permission means you can view the contents of a file or list the files in a directory. Write permission means you can modify the file or create/delete files inside a directory. Execute permission means you can run the file as a program or — crucially for directories — you can 'traverse' into them (i.e., cd into them even if you cannot list the contents).

These permissions are often represented numerically using octal (base-8) notation. Each permission gets a number: read = 4, write = 2, execute = 1. Add them together to get a single digit for each set. So rwx (all three) = 4+2+1 = 7. rw- (read and write, no execute) = 4+2+0 = 6. r-- (read only) = 4. A typical file permission might look like 755, which means:

- Owner: rwx (7)
- Group: r-x (5)
- Others: r-x (5)

To change these permissions, you use the chmod command. You can use symbolic mode (like chmod u+x file to add execute for the user) or numeric mode (like chmod 644 file to set owner read/write and everyone else read-only).

Ownership changes with chown and chgrp. chown changes the file's owner (and optionally the group). For example, chown alice:developers myfile sets the owner to alice and the group to developers. chgrp changes only the group, which is useful when you want to keep the existing owner unchanged.

The umask (user file-creation mode mask) is a default set of permissions that are automatically stripped away when a new file or directory is created. It's not a permission itself; it's a mask. A common umask value is 022, which subtracts write permission from group and others. So if the system default would create a file with full permissions (666 for files, 777 for directories), applying a umask of 022 results in a file being created with 644 (rw-r--r--) and a directory with 755 (rwxr-xr-x).

Special permissions add another layer. The setuid bit (represented as an 's' in the user's execute position) means that when a program runs, it runs with the privileges of the file's owner (often root), not the user who launched it. The setgid bit (an 's' in the group's execute position) does the same for the group, and also has a special effect on directories: new files created inside inherit the directory's group. The sticky bit (a 't' in the others' execute position) on a directory means that only the file owner can delete their own files within it — a classic example is /tmp.

These permissions are stored as part of the file's inode metadata. Every time you access a file, the kernel checks your user ID and group membership against the permission bits. If you are the owner, the owner set applies. If you are a member of the file's group, the group set applies. Otherwise, the others set applies. Only the first matching rule is used — there is no combining of permissions across different sets.

## Real-world context

Imagine you are the junior system administrator for a small e-commerce company. The company has a web server running a PHP application that stores customer orders in a database and uploads product images to a shared directory. Your job is to ensure that only the web server process (running as user 'www-data') can write to the uploads folder, but the developers (in the group 'webdev') need to be able to read the images and fix them if they are corrupted.

Step 1: Check current permissions. You run ls -l /var/www/html/uploads and see drwxrwxrwx — completely open to everyone. That is a security disaster: any user on the server could delete or replace product images with malicious content.

Step 2: Set ownership. You run chown -R www-data:webdev /var/www/html/uploads to make the owner www-data and the group webdev.

Step 3: Apply proper permissions. You want the owner (www-data) to have read, write, and execute (so the web server can write and enter the directory). You want the group (webdev) to have read and execute only (so they can see and browse but not modify). Others should have nothing. That is 750 in numeric form. You run chmod 750 /var/www/html/uploads.

Step 4: Test it. You try to create a file as the www-data user: it works. You try to delete a file as a random user: permission denied. A developer logs in and lists the directory: they can see files but cannot delete them.

Step 5: Set umask for new developers. You add umask 027 to the /etc/profile file so that any new file a developer creates will default to 640 (owner rw-, group r--, others nothing). This prevents accidental world-readable files containing database credentials.

Step 6: Use setgid on the shared project directory. You run chmod g+s /var/www/html/uploads so that any new subdirectory created inside — maybe by a script — automatically gets the 'webdev' group, not the user's primary group. This saves you from having to fix permissions manually every time a new upload folder is created.

The result is a secure, maintainable setup that follows the principle of least privilege — every user and process gets only the permissions they absolutely need to do their job.

## Exam focus

The LPIC-1 exam (specifically topic 103.3) is ruthless about testing your understanding of the numeric representation of permissions. You must be able to convert between symbolic (rwx) and octal (numeric) notation instantly. They will ask you: 'What permission is 755?' The answer is rwxr-xr-x. They will also ask the reverse: 'What numeric value corresponds to rw-r-----?' The answer is 640. Practise this until it is second nature.

Another classic question involves umask. They give you a umask value and a default file creation mode (usually 666 for files, 777 for directories) and ask what the resulting permissions will be. The trick: you subtract the umask from the default, but remember that the mask is applied to the default bits. For example, default 666 minus umask 022 is 644, but default 666 minus umask 027 is 640 — because you subtract bit by bit, not arithmetically. They love to test umask with values like 002, 027, 077.

Special permissions are a favourite trap. They ask: 'Which permission bit causes a program to run with the owner's identity?' That is setuid (chmod u+s). They might show you an ls -l output with an 's' in the user execute position and ask you to identify it. The same trick applies to setgid and the sticky bit. Remember: setuid is about the file's owner, not the user running it.

The difference between chown and chgrp is tested directly. They ask: 'Which command changes only the group ownership of a file?' The answer is chgrp. They also test that chown can change both owner and group in one command with the colon syntax (chown user:group file).

Permissions on directories vs files is a common confusion point. They will present a scenario: a user has write permission on a directory but not on a file inside it — can they delete the file? The answer is yes, because directory write permission controls the ability to add, remove, or rename entries. The file's own permissions only control reading or modifying its contents.

They also test the sticky bit: 'Which directory is a classic example of the sticky bit in use?' Answer: /tmp. They test understanding that the sticky bit prevents users from deleting other users' files, even if they have write permission on the directory.

Finally, they test the order of permission checking. The kernel checks owner first, then group, then others. Once a match is found, it applies that set and stops. This means if you are the owner, your group membership does not matter — the owner permissions apply exclusively.

## Step by step

1. **Check Current Permissions** — Run ls -l [filename] to view the existing permissions, owner, and group. This tells you what you are working with before making any changes.
2. **Decide on Required Permissions** — Determine who should be able to read, write, or execute. Follow the principle of least privilege — for a web server script, you might want owner rwx, group rx, and others nothing (750).
3. **Set Owner and Group with chown** — Use chown owner:group file to assign the correct user and group. For example, chown www-data:webdev script.sh ensures the web server can manage it and developers can view it.
4. **Apply Permissions with chmod** — Use chmod with either numeric (chmod 750 script.sh) or symbolic (chmod u=rwx,g=rx,o= script.sh) notation to set the permissions you decided in step 2.
5. **Set Default Permissions with umask** — Configure umask in a shell startup file (like ~/.bashrc or /etc/profile) to define the default permissions for files you create in the future. For example, umask 027 gives 640 for files and 750 for directories.
6. **Verify Changes** — Re-run ls -l to confirm the permissions display exactly what you intended. Also test as a different user (su or sudo -u) to ensure access works as expected.

## Comparisons

### chmod vs chown

**chmod:**
- Changes permissions (read, write, execute) of a file or directory.
- Can use numeric (e.g., 755) or symbolic (e.g., u+rwx) syntax.
- Does not change who owns the file.

**chown:**
- Changes ownership (user and/or group) of a file or directory.
- Requires root privileges to change the owner to another user.
- Does not directly change permissions.

### setuid vs setgid

**setuid:**
- Makes a program run with the privileges of the file owner (usually root).
- Shown as an 's' in the user's execute position in ls -l.
- Common on utilities like passwd that need elevated privileges.

**setgid:**
- Makes a program run with the privileges of the file's group.
- On a directory, makes new files inherit the directory's group.
- Shown as an 's' in the group's execute position.

### Read Permission on a Directory vs Write Permission on a Directory

**Read Permission on a Directory:**
- Allows listing of files and subdirectories inside.
- Without execute permission, cannot access any contents.
- R (read) alone is not enough to cd into the directory.

**Write Permission on a Directory:**
- Allows creating, deleting, and renaming files inside.
- Affects the directory's contents, not the files themselves.
- Without read permission, you can manipulate files but cannot see their names.

### chmod Symbolic Mode vs chmod Numeric Mode

**chmod Symbolic Mode:**
- Uses letters like u, g, o, a and operators +, -, =.
- Allows adding or removing specific permissions without affecting others.
- Example: chmod u+w file adds write for the owner.

**chmod Numeric Mode:**
- Uses three digits (0-7) representing owner, group, others.
- Sets all permissions at once — you cannot preserve existing ones.
- Example: chmod 644 file sets rw-r--r--.

### Sticky Bit vs No Sticky Bit

**Sticky Bit:**
- Prevents users from deleting files they do not own.
- Common on /tmp and /var/tmp directories.
- Shown as 't' in the others execute position.

**No Sticky Bit:**
- Any user with write permission can delete any file in the directory.
- Default behaviour for most directories.
- Can lead to accidental or malicious file deletion.

## Diagram

_This flowchart shows how file permissions are structured around owner, group, and others, and the commands used to modify them._

```mermaid
flowchart TD
    A[File or Directory] --> B[Owner (user)]
    A --> C[Group]
    A --> D[Others]
    B --> E[r = read, w = write, x = execute]
    C --> F[r, w, x]
    D --> G[r, w, x]
    E --> H[Octal: r=4, w=2, x=1]
    F --> H
    G --> H
    H --> I[chmod changes these]
    A --> J[chown changes owner/group]
    A --> K[umask sets defaults for new files]
```

## Common misconceptions

- **Misconception:** I can change any file's permissions if I own it, even if the file is owned by root. **Reality:** Only root (or a user with appropriate capabilities) can change the permissions of files they do not own, and even as owner you cannot change ownership to another user without root privileges. (New users confuse ownership with administrative power — they assume being the file owner gives them unlimited control, when in reality ownership only allows changing permissions, not transferring ownership.)
- **Misconception:** The execute permission on a file means the file will run automatically when I double-click it. **Reality:** Execute permission only means the file can be run as a program by the user; it does not make it auto-execute. You still need to invoke it (e.g., ./script.sh). (This comes from graphical operating systems where double-clicking launches the file regardless of permission bits — Linux separates the concept of 'being runnable' from 'being executed'.)
- **Misconception:** Setting permissions to 777 makes a file completely secure because everyone has access. **Reality:** 777 is the least secure permission — it grants full read, write, and execute to all users, including malicious ones. Secure permissions use the principle of least privilege, typically 755 for directories and 644 for files. (Beginners think 'everyone has access' means no one is locked out, but security is about restricting access, not granting it indiscriminately.)
- **Misconception:** The umask value is a permission setting I can apply directly to a file after creation. **Reality:** umask is a mask that subtracts from the default permissions when a file is created; it cannot be applied retroactively — you must use chmod to change permissions on existing files. (The word 'mask' sounds like a tool for editing, but it is actually a default filter. Beginners try to 'set umask' on a file they already created.)
- **Misconception:** If I have write permission on a directory, I can delete any file inside it regardless of that file's permissions. **Reality:** Correct — but only if the directory does not have the sticky bit set. If the sticky bit is active (e.g., /tmp), only the file owner or root can delete the file. (Users learn the rule 'directory write = delete any entry' and then forget the sticky bit exception, which is common on shared directories.)

## Key takeaways

- Permissions in Linux are defined for three entities: owner (user), group, and others, each with read, write, and execute bits.
- Use numeric (octal) mode like 755 or symbolic mode like u+rwx,g+rx,o+rx to set permissions with chmod.
- The chown command changes file owner and optionally group; chgrp changes only the group.
- umask sets default subtracted permissions for newly created files and directories — common values are 022 and 027.
- The setuid bit (chmod u+s) makes an executable run with the owner's privileges, while the setgid bit (chmod g+s) affects group inheritance on directories.
- The sticky bit (chmod +t) on a directory prevents users from deleting other users' files, even if they have write permission on that directory.
- Permission checking stops at the first matching set: owner, then group, then others — never combine.
- Always use the principle of least privilege: grant only the permissions a user or process absolutely needs.
- The chmod -R option recursively changes permissions on directories and their contents.
- The ls -l command displays permissions in the first column of its output, showing 10 characters (file type + 3 sets of 3 permissions).

## FAQ

**What is the difference between chmod and chown?**

chmod changes the permissions (read, write, execute) of a file or directory, while chown changes the ownership (which user and group own the file).

**How do I grant only read access to a file for everyone?**

Use chmod 444 filename — this gives read (4) to owner, group, and others, with no write or execute permissions.

**Can I remove the execute permission from a directory?**

Yes, but if you remove execute (x) from a directory, no one can cd into it or traverse it, even if they have read permission — they can only list files if they also have read, but cannot access any contents.

**Why does my file have a 't' at the end of its permissions?**

That is the sticky bit, shown as a 't' in the others execute position. It means only the file owner or root can delete or rename files inside that directory, even if others have write permission.

**How do I see the umask value for my current session?**

Type umask without any arguments — it will display the current mask in either numeric (e.g., 0022) or symbolic form (e.g., u=rwx,g=rx,o=rx).

**What is a 'setuid' binary and why is it dangerous?**

A setuid binary runs with the permissions of the file's owner (usually root) regardless of who executes it. This is dangerous because if a user can exploit a setuid program, they could gain root privileges.

## Check your understanding

1. **What does the permission string 'drwxr-xr--' mean in octal?**

   Answer: It means the directory has owner rwx (7), group r-x (5), and others r-- (4), so the octal representation is 754.

2. **If a file has permissions 600 and is owned by root, can a regular user read it?**

   Answer: No, because 600 gives only owner (root) read and write — group and others have no permissions (0), so they cannot read it.

3. **What command would you use to change the group ownership of a file to 'developers' while keeping the same owner?**

   Answer: Use chgrp developers filename.

4. **What is the default umask on most Linux systems, and what permissions does it give to a new file?**

   Answer: The default umask is often 022, which when applied to the default file permission 666 results in 644 (rw-r--r--).

5. **Why would you place the sticky bit on a directory like /tmp?**

   Answer: To prevent users from deleting or renaming files that belong to other users, even though they have write permission on the directory.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/lpi-lpic1/file-management-and-permissions