# Files & Directory Permissions In Linux, user management is a fundamental aspect of system administration and security. At the heart of this system is the concept of **user roles** and **groups**, which determine what actions users can perform and what resources they can access. The most powerful user in Linux is the **root user**, often referred to as the **superuser**. The root user has unrestricted access to the entire system, allowing them to perform any task, modify any file, and change system configurations. This level of access is necessary for administrative tasks but can also pose significant security risks if misused. In contrast to the root user, **regular users** have limited permissions. These users are typically restricted to their own files and directories and cannot make system-wide changes. This separation of privileges is a core principle of Linux security, ensuring that most users operate within a controlled environment that minimizes the risk of accidental or intentional damage to the system. ## Adding a user Adding a new user in Linux is a simple process that can be accomplished using the command line. To begin, open your terminal and ensure you have administrative privileges, either by logging in as the **root user** or using `sudo` to execute commands with elevated permissions. The easiest way to add a new user is by using the `adduser` command, which is interactive and guides you through the process. For example, to create a user named `john`, you would run the command `sudo adduser john`. The system will prompt you to set a password for the new user and may ask for additional details, such as the user's full name, room number, or phone number. These fields are optional and can be skipped by pressing `Enter`. ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ sudo adduser john [sudo] password for kali: info: Adding user `john' ... info: Selecting UID/GID from range 1000 to 59999 ... info: Adding new group `john' (1002) ... info: Adding new user `john' (1002) with group `john (1002)' ... info: Creating home directory `/home/john' ... info: Copying files from `/etc/skel' ... New password: Retype new password: passwd: password updated successfully Changing the user information for john Enter the new value, or press ENTER for the default Full Name []: john Room Number []: 123 Work Phone []: Home Phone []: Other []: Is the information correct? [Y/n] y info: Adding new user `john' to supplemental / extra groups `users' ... info: Adding user `john' to group `users' ... ``` Once the user is created, you can verify their existence by checking the `/etc/passwd` file, which stores user account information. For example, running `grep john /etc/passwd` will display a line with the user's details, confirming that the account has been successfully created. ```jsx ┌──(kali㉿kali)-[~/Desktop] └─$ grep john /etc/passwd john:x:1002:1002:john,123,,:/home/john:/bin/bash ``` ## Groups in Linux To simplify user management and permission assignment, Linux organizes users into **groups**. A group is a collection of users who share similar access needs. For example, In an IT or technical environment, groups might include: * **Developers**: For software engineers who need access to programming tools and repositories. * **Network Administrators**: For IT staff responsible for managing network infrastructure. * **Database Administrators**: For users who manage and maintain databases. By assigning users to groups, administrators can efficiently manage permissions. Instead of setting permissions for each individual user, permissions are assigned to the group, and all members of that group inherit those permissions. This approach not only simplifies administration but also ensures consistency and reduces the risk of errors. Groups play a critical role in maintaining a secure and organized system. They allow administrators to: 1. **Streamline Permission Management**: Instead of assigning permissions to individual users, permissions are assigned to groups, making it easier to manage access for multiple users with similar roles. 2. **Enhance Security**: By limiting access to sensitive files and directories to specific groups, administrators can reduce the risk of unauthorized access. 3. **Improve Collaboration**: Groups enable users with similar responsibilities to share resources and collaborate effectively. To add a new group called developers we can use `groupadd`: ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ sudo groupadd developers [sudo] password for kali: ``` We can verify if the group was created or not by checking entry at `/etc/group` file. ## Types of Groups ### Primary Groups In Linux, users are associated with both **primary groups** and **secondary groups**, each serving a specific purpose in managing permissions and access. When a user account is created, it is assigned a **primary group**, which is typically named after the user. For example, if the username is `john`, the primary group might also be named `john`. This primary group plays a key role in determining the default group ownership of files and directories created by the user. Whenever a user creates a new file or directory, the system automatically assigns the primary group as the group owner of that file or directory. A user can belong to only one primary group at a time, and this information is stored in the `/etc/passwd` file. ### Secondary Groups In addition to the primary group, a user can also belong to **secondary groups**. These are additional groups that provide the user with extra permissions beyond those granted by their primary group. Secondary groups are particularly useful in environments where users need access to resources shared among multiple teams or roles. For example, a user might have a primary group for their personal files but also belong to secondary groups like `developers`, `admins`, or `finance` to access shared resources related to those roles. A user can belong to multiple secondary groups, and this information is stored in the `/etc/group` file. By organizing users into primary and secondary groups, Linux provides a flexible and efficient way to manage permissions, ensuring that users have the access they need while maintaining security and organization. ## Adding `john` User to `developers` Group ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ sudo usermod -aG developers john ┌──(kali㉿kali)-[~/Desktop] └─$ cat /etc/group | grep 'developers' developers:x:1003:john ``` ## Granting Permissions #### Granting Permissions In Linux, file and folder permissions are a core component of the system's security and access control mechanism. Each file and folder has a set of permissions that determine how users can interact with them. Each file and directory in Linux must be assigned specific permissions to control access for different users. These permissions are divided into three levels: * **`r` (Read permission):** This allows a user to open and view the contents of a file or list the contents of a directory. However, it does not permit any modifications or execution. * **`w` (Write permission):** This grants the ability to modify a file’s contents or add, delete, and rename files within a directory. It also implies the ability to read the file or directory. * **`x` (Execute permission):** This permits a user to execute a file as a program or script. For directories, it allows the user to traverse and access files within the directory, provided they have the necessary permissions. These permissions are assigned to three categories of users: the **owner** of the file, the **group** associated with the file, and **others** (all other users). By default, when a file is created, the user who created it becomes the owner, and the owning group is set to the user’s current group. The owner has the authority to modify permissions and grant access to other users or groups as needed. To manage these permissions, commands like `chmod` are used to change access levels, `chown` to change ownership, and `chgrp` to modify the group associated with the file or directory. This system ensures that users have the appropriate level of access based on their roles and responsibilities, maintaining security and organization within the system. 
┌──(kali㉿kali)-[~/Desktop]
└─$ touch test.txt

┌──(kali㉿kali)-[~/Desktop]
└─$ mkdir test

┌──(kali㉿kali)-[~/Desktop]
└─$ ls -l
total 4
drwxrwxr-x 2 kali kali 4096 Feb 27 10:05 test
-rw-rw-r-- 1 kali kali    0 Feb 27 10:05 test.txt
Let’s break down the file permissions of above code snippet in a simple way: 1. **`drwxrwxr-x` (for the `test` directory)**: * **`d`**: This means it’s a **directory** (not a file). * **`rwx`**: The **owner** (`kali`) has **read (r)**, **write (w)**, and **execute (x)** permissions. This means the owner can view, modify, and enter the directory. * **`rwx`**: The **group** (`kali`) also has **read**, **write**, and **execute** permissions. Members of the group can do the same as the owner. * **`r-x`**: **Others** (everyone else) have **read** and **execute** permissions. They can view and enter the directory but cannot modify it. 2. **`rw-rw-r--` (for the `test.txt` file)**: * `-`: This means it’s a **regular file** (not a directory). * **`rw-`**: The **owner** (`kali`) has **read** and **write** permissions. The owner can view and edit the file but cannot execute it (since it’s not a program). * **`rw-`**: The **group** (`kali`) also has **read** and **write** permissions. Group members can view and edit the file. * **`r--`**: **Others** (everyone else) have only **read** permission. They can view the file but cannot edit or execute it. * **`kali kali`**: * The first `kali` is the **owner** of the directory (`test`). This means the user `kali` created or owns this directory. * The second `kali` (primary group) is the **group** associated with the directory. In this case, the group is also named `kali`. File permissions ensure that only authorized users can access or modify files, maintaining security and control over the system. They can be changed using the `chmod` command. ### Changing Permissions with Decimal Notation In Linux, file permissions can be changed using **decimal notation**, also known as **octal notation**, which is a numeric way to represent permissions. Each permission type—**read (r)**, **write (w)**, and **execute (x)**—is assigned a specific value: **read = 4**, **write = 2**, and **execute = 1**. These values are added together to create a single digit that represents the permissions for a specific user category (owner, group, or others). For example: * If you want to give **read and write** permissions, you add 4 (read) + 2 (write) = **6**. * If you want to give **read, write, and execute** permissions, you add 4 (read) + 2 (write) + 1 (execute) = **7**. To set permissions for a file or directory, you combine three digits: one for the **owner**, one for the **group**, and one for **others**. For instance: * **755**: This means: * **7** (owner): read (4) + write (2) + execute (1) = full permissions. * **5** (group): read (4) + execute (1) = read and execute. * **5** (others): read (4) + execute (1) = read and execute. To apply these permissions, you use the `chmod` command followed by the numeric value and the file or directory name. For example: ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ chmod 755 test.txt ┌──(kali㉿kali)-[~/Desktop] └─$ ls -l total 4 drwxrwxr-x 2 kali kali 4096 Feb 27 10:05 test -rwxr-xr-x 1 kali kali 0 Feb 27 10:05 test.txt ``` This command gives the owner full permissions, while the group and others get read and execute permissions. Decimal notation is a quick and efficient way to set permissions, especially when you need to apply the same permissions to multiple files or directories. It ensures precise control over who can read, write, or execute files and directories in a Linux system. Let’s go through another example step by step using **decimal notation** to set file permissions. Suppose you want to assign the following permissions: 1. **Owner**: You want to give **read (r) and write (w)**, permissions. * Read = **4**, Write = **2**. * Add them together: 4 + 2 = 6. * So, the owner’s permission value is 6. 2. **Group**: You want to give **read (r)** and **execute (x)** permissions. * Read = **4**, Execute = **1**. * Add them together: 4 + 1 = **5**. * So, the group’s permission value is **5**. 3. **Others**: You want to give only **execute (x)** permission. * Execute = **1**. * So, the others’ permission value is **1**. Now, combine these three values in the order: **owner**, **group**, **others**. This gives you the numeric permission value: 6**51**. ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ chmod 651 test.txt ┌──(kali㉿kali)-[~/Desktop] └─$ ls -l total 4 drwxrwxr-x 2 kali kali 4096 Feb 27 10:05 test -rw-r-x--x 1 kali kali 0 Feb 27 10:05 test.txt ``` ## Changing Permissions with UGO In Linux, **UGO** is a simple and intuitive way to change file or directory permissions using symbolic notation. UGO stands for **User (owner)**, **Group**, and **Others**, which are the three categories of users for whom permissions can be set. Each category can be assigned **read (r)**, **write (w)**, or **execute (x)** permissions. The `chmod` command is used to change permissions in this format. * **U (User/Owner)**: Refers to the owner of the file or directory. * **G (Group)**: Refers to the group associated with the file or directory. * **O (Others)**: Refers to all other users who are not the owner or part of the group. You can add (`+`), remove (`-`), or set (`=`) permissions for any of these categories. For example: * `u+r` adds read permission for the owner. * `g-w` removes write permission for the group. * `o=x` sets execute permission for others (and removes all other permissions). Let’s use the file `test.txt` from example to demonstrate how to change permissions using **UGO notation**. Here’s the initial state of the file ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ ls -l total 4 drwxrwxr-x 2 kali kali 4096 Feb 27 10:05 test -rw-r-x--x 1 kali kali 0 Feb 27 10:05 test.txt ``` #### Initial Permissions: * **Owner (u)**: `rw-` (read and write). * **Group (g)**: `r-x` (read and execute). * **Others (o)**: `-x` (execute only). **Add execute permission for the owner**: ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ chmod u+x test.txt ``` * This adds execute (`x`) permission for the **owner**. * New permissions: `rwxr-x--x`. **Remove write permission for the group**: ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ chmod g-w test.txt ``` * This removes write (`w`) permission for the **group**. * New permissions: `rwxr-x--x`. **Set read-only permission for others**: ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ chmod o=r test.txt ``` * This sets read (`r`) permission for **others** and removes any other permissions they had. * New permissions: `rwxr-xr--`. **Remove all permissions for the group**: ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ chmod g= test.txt ┌──(kali㉿kali)-[~/Desktop] └─$ ls -l total 4 drwxrwxr-x 2 kali kali 4096 Feb 27 10:05 test -rwx---r-- 1 kali kali 0 Feb 27 10:05 test.txt ``` * This removes all permissions for the **group**. * New permissions: `rwx---r--`. #### Granting Ownership to an Individual User In Linux, every file and directory is associated with an **owner** and a **group**. The owner is typically the user who created the file, but ownership can be transferred to another user if needed. This is useful when a file needs to be managed by a different user, such as transferring responsibility or granting access. To change the owner of a file or directory, the `chown` command is used. Only the **root user** or a user with **sudo privileges** can change ownership of a file. For example, let’s say you have a file called `test.txt` owned by the user `kali`, and you want to transfer ownership to another user named `john`. You would use the following command: ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ sudo chown john test.txt [sudo] password for kali: ┌──(kali㉿kali)-[~/Desktop] └─$ ls -l -rwx---r-- 1 john kali 0 Feb 27 10:05 test.txt ``` #### Granting Ownership to a Group In Linux, files and directories are not only associated with an individual owner but also with a **group**. Groups allow multiple users to share access to files with specific permissions. Granting ownership to a group is useful when you want a team or set of users to collectively manage or access a file or directory. To change the group ownership of a file or directory, the `chown` or `chgrp` command is used. Only the **root user** or a user with **sudo privileges** can change group ownership. For example, let’s say you have a file called `test.txt` owned by the user `john` and the group `kali`, and you want to grant ownership to a group called `developers`. You would use the following command: ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ sudo chgrp developers test.txt ┌──(kali㉿kali)-[~/Desktop] └─$ ls -l total 0 -rwx---r-- 1 john developers 0 Feb 27 10:05 test.txt ``` #### Setting More Secure Default Permissions with Masks In Linux, the **umask** (user file-creation mask) is a setting that determines the default permissions for newly created files and directories. It works by "masking out" or restricting certain permissions to ensure that files and directories are created with more secure and restrictive permissions by default. The `umask` value is subtracted from the base permissions (typically `666` for files and `777` for directories) to determine the final permissions. For example, a common `umask` value is `022`, which means: * For **files**: Base permissions are `666` (read and write for owner, group, and others). Subtracting the `umask` of `022` results in default file permissions of `644` (`rw-r--r--`), where the owner has read and write permissions, while the group and others have only read permissions. * For **directories**: Base permissions are `777` (read, write, and execute for owner, group, and others). Subtracting the `umask` of `022` results in default directory permissions of `755` (`rwxr-xr-x`), where the owner has full permissions, while the group and others have read and execute permissions. The `umask` can be set temporarily for the current session using the `umask` command or permanently by adding it to a user's shell configuration file (e.g., `.bashrc` or `.profile`). For example, to set a more restrictive `umask` of `027`, you would use: ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ touch test1 ┌──(kali㉿kali)-[~/Desktop] └─$ ls -l total 0 -rw-r--r-- 1 kali kali 0 Feb 27 11:30 test1 ┌──(kali㉿kali)-[~/Desktop] └─$ umask 027 ┌──(kali㉿kali)-[~/Desktop] └─$ touch test2 ┌──(kali㉿kali)-[~/Desktop] └─$ ls -l total 0 -rw-r--r-- 1 kali kali 0 Feb 27 11:30 test1 -rw-r----- 1 kali kali 0 Feb 27 11:32 test2 ``` Let's breakdown each commands below: #### 1. **Initial State**: * The command `touch test1` creates a new file called `test1`. * By default, the file is created with permissions `rw-r--r--` (644): * **Owner**: Read and write (`rw-`). * **Group**: Read only (`r--`). * **Others**: Read only (`r--`). #### 2. **Changing the umask**: * The command `umask 027` sets a new **umask** value: * The `umask` of `027` means: * **Owner**: No permissions are masked (full permissions allowed). * **Group**: Write permission is masked (`2`). * **Others**: Read, write, and execute permissions are masked (`7`). #### 3. **Creating a New File with the New umask**: * The command `touch test2` creates a new file called `test2`. * With the `umask` set to `027`, the file is created with permissions `rw-r-----` (640): * **Owner**: Read and write (`rw-`). * **Group**: Read only (`r--`). * **Others**: No permissions (`--`). #### 4. **Result**: * The `ls -l` command shows the permissions for both files: * `test1`: Created with the default `umask`, has permissions `rw-r--r--`. * `test2`: Created with the `umask` of `027`, has more restrictive permissions `rw-r-----`. #### Special Permissions In addition to the standard permissions—read (r), write (w), and execute (x)—Linux also supports three special permissions that offer more advanced functionality. These are the **Set User ID (SUID)**, **Set Group ID (SGID)**, and **Sticky Bit**. Each of these permissions serves a unique purpose and provides additional control over how files and directories are accessed or executed. I will explore each of these special permissions in detail in the following sections. #### Granting Temporary Root Permissions with SUID In Linux, a user can only execute a file if they have the **execute (x)** permission for that file. Without execute permission, even if a user has read or write access, they cannot run the file. However, there are exceptions to this rule, particularly when a file needs to perform tasks that require elevated privileges, such as those of the **root user**. For example, consider a program that allows users to change their passwords. This program needs access to the `/etc/shadow` file, which stores encrypted user passwords and is only accessible by the root user. To allow non-root users to execute such a program, Linux provides a mechanism called the **Set User ID (SUID)** bit. When the SUID bit is set on a file, any user who executes the file temporarily inherits the permissions of the file’s **owner** (often root) during the execution of that file. This allows the program to perform tasks that would otherwise require root privileges, but the elevated permissions are limited to the execution of that specific file and do not extend beyond it. To set the SUID bit, you prepend a **4** to the file’s permission code. For instance, if a file has permissions `644` (read and write for the owner, and read-only for the group and others), setting the SUID bit changes the permission code to `4644`. This ensures that the file retains its original permissions while enabling the SUID functionality. Setting the SUID bit is typically done by system administrators and is not something an average user would configure. To set the SUID bit on a file, you use the `chmod` command. For example: ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ chmod 4644 test1 ┌──(kali㉿kali)-[~/Desktop] └─$ ls -l total 0 -rwSr--r-- 1 kali kali 0 Feb 27 11:30 test1 -rw-r----- 1 kali kali 0 Feb 27 11:32 test2 ``` * When the SUID bit is set on a file, any user who executes the file temporarily inherits the permissions of the file’s **owner** (in this case, `kali`) during execution. * This is useful for programs that need elevated privileges (e.g., changing passwords), but it should be used carefully to avoid security risks. #### **Granting the Root User’s Group Permissions SGID** The **SGID (Set Group ID)** bit is a special permission in Linux that grants temporary elevated permissions, but unlike SUID, it grants the permissions of the file owner’s **group** rather than the file owner themselves. This means that if the SGID bit is set on a file, any user who executes the file will temporarily inherit the permissions of the group associated with the file, even if they don’t belong to that group. This is particularly useful for files that need to be executed by multiple users who share the same group permissions. For example, if a file is owned by the group `developers` and has the SGID bit set, any user running the file will execute it with the permissions of the `developers` group, regardless of their own group membership. When the SGID bit is applied to a **directory**, it behaves differently. In this case, any new files or subdirectories created within that directory will inherit the group ownership of the parent directory, rather than the primary group of the user who created the file. This is especially useful in shared environments where multiple users need to collaborate and access files within the same directory. For instance, if a directory has the SGID bit set and is owned by the group `team`, any file created within that directory will automatically belong to the `team` group, ensuring seamless collaboration among group members. To set the SGID bit, you add a **2** before the regular permission code. For example, if a file has permissions `644` (read and write for the owner, and read-only for the group and others), setting the SGID bit changes the permission code to `2644`. You can set the SGID bit using the `chmod` command, For example: ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ chmod 2644 test2 ┌──(kali㉿kali)-[~/Desktop] └─$ ls -l total 0 -rwSr--r-- 1 kali kali 0 Feb 27 11:30 test1 -rw-r-Sr-- 1 kali kali 0 Feb 27 11:32 test2 ``` #### Sticky Bit The **sticky bit** in Linux is a special permission applied to directories to restrict file deletion. When the sticky bit is set, only the **owner** of a file, the **owner of the directory**, or the **root user** can delete or rename files within that directory, even if other users have write permissions. This feature is particularly useful in shared directories, such as **`/tmp`**, where multiple users have access. Without the sticky bit, any user with write access could delete or modify files owned by others. By enabling it, system administrators can prevent accidental or malicious file deletions in shared spaces, ensuring better security and control. ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ mkdir test ┌──(kali㉿kali)-[~/Desktop] └─$ chmod +t test ┌──(kali㉿kali)-[~/Desktop] └─$ ls -l drwxr-x--T 2 kali kali 4096 Feb 27 12:00 test ``` * **`t` (lowercase)** → Sticky bit is set, and others have **execute (`x`) permission**. Example: `drwxrwxrwt` (like `/tmp`). * **`T` (uppercase)** → Sticky bit is set, but others **do not have execute (`x`) permission**. ## Special Permissions and Privilege Escalation As a hacker, special permissions can be exploited to gain **privilege escalation** in Linux systems, allowing a regular user to obtain **root** or **sysadmin** privileges. Once root access is achieved, you gain complete control over the system. One common way to escalate privileges is by exploiting the **SUID bit**. System administrators or developers often set the **SUID bit** on certain programs to allow them to execute with **elevated privileges**. For example, scripts that manage password changes typically have the **SUID bit** enabled. As an attacker, you can leverage this permission to gain **temporary root access**, potentially accessing sensitive files like **`/etc/shadow`**, which stores system passwords. To identify files with the **SUID bit** on a Kali Linux system, we can use the **find** command. Previously, in Chapter 1, we explored the power of the **find** command, which allows precise file searches. Unlike simpler commands like **locate** or **which**, **find** has a more complex syntax, but it offers greater flexibility. If needed, you can review its syntax before proceeding. In this case, we want to search the entire filesystem for files owned by **root** that have the **SUID permission bit (4000)**. The following **find** command accomplishes this: ```bash ┌──(kali㉿kali)-[~/Desktop] └─$ find / -user root -perm -4000 2>/dev/null /usr/lib/chromium/chrome-sandbox /usr/lib/openssh/ssh-keysign /usr/lib/polkit-1/polkit-agent-helper-1 /usr/lib/dbus-1.0/dbus-daemon-launch-helper /usr/lib/xorg/Xorg.wrap /usr/bin/rsh-redone-rlogin /usr/bin/ntfs-3g /usr/bin/kismet_cap_nrf_52840 /usr/bin/pkexec /usr/bin/mount ---snip--- ``` 1. **`find /`** → Starts searching from the root (`/`) directory, meaning it will scan the entire filesystem. 2. **`user root`** → Filters results to show only files owned by the **root** user. 3. **`perm -4000`** → Searches for files with the **SUID (Set User ID) bit** set. The `4000` permission indicates that the file runs with the privileges of its owner (root). 4. **`2>/dev/null`** → Redirects error messages to `/dev/null`, preventing permission-denied errors from being displayed. This command is used to **find all SUID-enabled files** owned by root. These files can be potential security risks because they allow **privilege escalation** if exploited. Hackers or pentesters use this to identify weak points in a system. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://handbook.ncateam.xyz/fundamentals/linux/files-and-directory-permissions.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.