# Linux Permissions

Access to any file or directory in Linux is controlled by file permissions

# Types of File Permissions:

1. ### Basic Permission
    
2. ### Access Control List (ACL) permission
    
3. ### Special Permission
    

### Basic Permission

File permissions are represented using a combination of characters: r (read), w (write), and x (execute). These characters are assigned to the three categories of users in the following order: owner, group, and others.Linux basic file permission is very simple and flexible to apply. The permission string format is as follows:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1689842480863/a4751d4d-4f89-408f-a80b-574e49b0ce27.png align="center")

The first character in `-rw-rw-r--`indicates the type of file: "-" for a regular file, "d" for a directory, "l" for a symbolic link, and so on.

```bash
ubuntu@ip-172-31-81-167:~$ sudo useradd -m Mahi
ubuntu@ip-172-31-81-167:~$ sudo groupadd CSK
ubuntu@ip-172-31-81-167:~$ ls -ltr
drwxrwxr-x 2 ubuntu ubuntu 4096 Jul 20 08:58 chennai
ubuntu@ip-172-31-81-167:~$ sudo chown Mahi chennai/
ubuntu@ip-172-31-81-167:~$ sudo chgrp CSK chennai/
ubuntu@ip-172-31-81-167:~$ ls -ltr
drwxrwxr-x 2 Mahi   CSK    4096 Jul 20 08:58 chennai
```

For example, if the file permissions are `rw-r--r--`, it means:

* The owner has read and write permissions. 👩‍💻✍️
    
* The group has read-only permissions. 👥👀
    
* Others have read-only permissions. 👥👀
    

Let's understand in deep the above example:

```bash
drwxrwxr-x 2 Mahi CSK 4096 Jul 20 08:58 chennai
```

1. `d`: The first character represents the type of file. In this case, it is a directory. If it were a regular file, it would be represented as `-`.
    
2. `rwxrwxr-x`: The next nine characters are the file permissions, grouped in sets of three. Each set represents the permissions for the owner, group, and others, respectively.
    
    * `rwx` (Owner): The owner (Mahi in this case) has read, write, and execute permissions on the directory. This means the owner can view the contents of the directory, create new files or subdirectories, and enter (cd into) the directory.
        
    * `rwx` (Group): The group (CSK in this case) also has read, write, and execute permissions on the directory. Group members can perform the same actions as the owner.
        
    * `r-x` (Others): The others have read and execute permissions but not write permissions. Others can view the directory's contents and enter it, but they cannot modify or create files in it.
        
3. `2`: The number 2 represents the link count of the directory. A link count greater than 2 would indicate that there are hard links pointing to this directory.
    
4. `Mahi`: This is the owner of the directory. The user "Mahi" is the one who has control over the permissions and ownership settings for this directory.
    
5. `CSK`: This is the group associated with the directory. Members of the "CSK" group share the same group permissions as defined in the permissions section.
    
6. `4096`: The number 4096 indicates the size of the directory in bytes.
    
7. `Jul 20 08:58`: This represents the date and time when the directory was last modified.
    
8. `chennai`: This is the name of the directory.
    

In summary, this example shows a directory named "chennai" that is owned by the user "Mahi" and belongs to the group "CSK." The owner and group have full read, write, and execute permissions, while others can only read and execute the directory.

**Changing the File Permissions using** `chmod`

You can modify file permissions using the `chmod` command. The syntax for `chmod` is as follows:

```bash
chmod permissions file_name
```

The permissions can be represented numerically or symbolically.

### **Numeric Representation:**

* `4` (r) - Read permission 👀
    
* `2` (w) - Write permission ✍️
    
* `1` (x) - Execute permission 🏃‍♂️
    
* `0` - No permission 🚫
    

For example, to give read and write permissions to the owner and read-only permissions to the group and others, you can use the numeric representation:

```bash
ubuntu@ip-172-31-81-167:~$ chmod 644 file1.txt
ubuntu@ip-172-31-81-167:~$ ls -ld file1.txt
-rw-r--r-- 1 ubuntu ubuntu 0 Jul 20 08:20 file1.txt
```

### **Symbolic Representation:**

* `u` - Owner 👩‍💻
    
* `g` - Group 👥
    
* `o` - Others 👥
    
* `a` - All users (equivalent to `ugo`) 👪
    
* `+` - Add the specified permission ➕
    
* `-` - Remove the specified permission ➖
    
* `=` - Set the specified permission explicitly 🎯
    

For example, to give read and write permissions to the owner and read-only permissions to the group and others, you can use the symbolic representation:

```bash
ubuntu@ip-172-31-81-167:~$ chmod u+x,g+w,o+r file1.txt
ubuntu@ip-172-31-81-167:~$ ls -ld file1.txt
-rwxrw-r-- 1 ubuntu ubuntu 0 Jul 20 08:20 file1.txt
```

1. ### ACL-Acess Control List
    
    Linux also supports Access Control Lists (ACLs) that provide more fine-grained control over file permissions. ACLs allow you to set permissions for specific users and groups beyond the traditional owner, group, and others. To view the ACL of a file, use the `getfacl` command, and to set ACL, use the `setfacl` command.
    
    ```bash
    getfacl file.txt
    setfacl -m u:user:rwx file.txt
    ```
    
    ACLs can be very useful in complex scenarios where standard permissions may not suffice.
    

````bash
📁 List current Access Control List (ACL) for "chennai/" directory:
```bash
ubuntu@ip-172-31-81-167:~$ getfacl chennai/
# file: chennai/
# owner: Mahi
# group: CSK
user::rwx
group::rwx
other::r-x
````

🔒 Attempt to grant read and write permissions to user "Manish" but fail due to insufficient permissions:

```bash
ubuntu@ip-172-31-81-167:~$ setfacl -m u:Manish:rw chennai/
setfacl: chennai/: Operation not permitted
```

✅ Retry with superuser (sudo) privileges and successfully grant "Manish" read and write permissions:

```bash
ubuntu@ip-172-31-81-167:~$ sudo setfacl -m u:Manish:rw chennai/
```

📁 Check the updated ACL, now showing "Manish" with read and write permissions:

```bash
ubuntu@ip-172-31-81-167:~$ getfacl chennai/
# file: chennai/
# owner: Mahi
# group: CSK
user::rwx
user:Manish:rw-
group::rwx
mask::rwx
other::r-x
```

🔒 Attempt to grant access level '7' to user "Keshav" but fail due to incorrect syntax:

```bash
ubuntu@ip-172-31-81-167:~$ sudo setfacl -m u:Keshav:7 chennai/
setfacl: Option -m: Invalid argument near character 3
```

🔒 Remove ACL entry for user "Manish," revoking their permissions:

```bash
ubuntu@ip-172-31-81-167:~$ sudo setfacl -x u:Manish: chennai/
```

📁 Verify the updated ACL, confirming the removal of "Manish" from the ACL:

```bash
ubuntu@ip-172-31-81-167:~$ getfacl chennai/
# file: chennai/
# owner: Mahi
# group: CSK
user::rwx
group::rwx
mask::rwx
other::r-x
```

✅ Grant access level '7' (read, write, execute) to group "CSK":

```bash
ubuntu@ip-172-31-81-167:~$ sudo setfacl -m g:CSK:7 chennai/
```

📁 Check the updated ACL, showing "CSK" with read, write, and execute permissions:

```bash
ubuntu@ip-172-31-81-167:~$ getfacl chennai/
# file: chennai/
# owner: Mahi
# group: CSK
user::rwx
group::rwx
group:CSK:rwx
mask::rwx
other::r-x
```

🔑 Please note that ACLs can coexist with standard Unix file permissions, providing additional granularity in access control. The output of "getfacl" shows both the standard permissions (user::rwx, group::rwx, other::r-x) and the ACL entries (e.g., user:Manish:rw-, group:CSK:rwx).

Let's consider a software development project as an example:

1. **Project Directory Structure:**
    

```bash
code/project
    ├── code
    │   ├── main.c
    │   └── utility.c
    ├── docs
    │   ├── design.docx
    │   └── requirements.txt
    ├── tests
    │   ├── unit_tests.py
    │   └── integration_tests.py
    └── reports
        └── weekly_report.pdf
```

**User Groups and Their Access Requirements:**

* **Developers Group (dev\_group):** They need full access to the "code" directory for reading, writing, and executing the source code files.
    
* **Testers Group (test\_group):** They should be able to read and execute the code files in the "code" directory for testing purposes. They also need read access to the "tests" directory.
    
* **Project Managers (pm\_group):** They require read access to all directories, including "code," "docs," "tests," and "reports," to oversee the project's progress.
    
* **Administrators (admin\_group):** The administrators need full access to all directories to manage user permissions and handle other administrative tasks.
    

**Using ACLs:**

To achieve the necessary access control, traditional file permissions (rwx) might not be enough. This is where ACLs come into play.

For example, we can set ACLs as follows:

```bash
setfacl -m g:dev_group:rwx /project/code
setfacl -m g:test_group:r-x /project/code
setfacl -m g:pm_group:r-x /project
setfacl -m g:admin_group:rwx /project
setfacl -m g:test_group:r-- /project/tests
setfacl -m g:pm_group:r-- /project/docs
```

Now, each group has the necessary access permissions:

* Members of the "dev\_group" can fully read, write, and execute the files in the "code" directory.
    
* Members of the "test\_group" can read and execute the files in the "code" directory and read the files in the "tests" directory.
    
* Members of the "pm\_group" can read the entire project directory, including "code," "docs," "tests," and "reports."
    
* Administrators have full control over the entire project directory.
    

With ACLs, this level of fine-grained access control can be achieved, allowing different teams to collaborate effectively while maintaining proper security and confidentiality. ACLs provide a powerful tool for managing access to files and directories beyond the standard owner-group-others permissions model.

* ### Special Permissions
    
    In Linux, special permissions, also known as "special mode bits" or "setuid, setgid, and sticky bit," are additional settings that can be applied to files and directories in addition to the standard read (r), write (w), and execute (x) permissions. These special permissions allow for more sophisticated control over how files and directories are accessed and executed by users and processes.The special permissions include:
    
* SUID (Set User ID)
    
* SGID (Set Group ID)
    
* Sricky Bit
    

**SUID (Set User ID)**: When set on an executable file, the process that runs the file will temporarily have the effective user ID of the owner of the file, rather than the user running the process. This is useful for allowing users to execute a program with privileges they don't usually have. The setuid permission is represented by the numeric value 4.

1. **List details of the file before setting SUID:**
    

```bash
ubuntu@ip-172-31-81-167:~$ sudo ls -ld /usr/bin/nmtui
-rwxr-xr-x 1 root root 751976 Jun  9  2022 /usr/bin/nmtui
```

The `/usr/bin/nmtui` file has the permissions `-rwxr-xr-x`, and it is owned by the root user and the root group. The file is an executable because of the 'x' permission in the user, group, and other sections.

1. **Attempt to set the SUID bit without superuser privileges (fails):**
    

```bash
ubuntu@ip-172-31-81-167:~$ chmod u+s /usr/bin/nmtui
chmod: changing permissions of '/usr/bin/nmtui': Operation not permitted
```

The command `chmod u+s` tries to set the SUID bit for the file, but it fails because regular users do not have the permission to set the SUID bit on files they don't own.

1. **Set the SUID bit using sudo (succeeds):**
    

```bash
ubuntu@ip-172-31-81-167:~$ sudo chmod u+s /usr/bin/nmtui
```

By using `sudo`, we elevate our privileges and successfully set the SUID bit for the `/usr/bin/nmtui` file.

1. **List details of the file after setting SUID:**
    

```bash
ubuntu@ip-172-31-81-167:~$ sudo ls -ld /usr/bin/nmtui
-rwsr-xr-x 1 root root 751976 Jun  9  2022 /usr/bin/nmtui
```

Now, the `/usr/bin/nmtui` file has the SUID bit set. The permission string shows `-rwsr-xr-x`, where the 's' in the user section indicates the SUID bit is set.

1. **Remove the SUID bit using sudo:**
    

```bash
ubuntu@ip-172-31-81-167:~$ sudo chmod u-s /usr/bin/nmtui
```

With `sudo`, we remove the SUID bit from the `/usr/bin/nmtui` file.

1. **List details of the file after removing SUID:**
    

```bash
ubuntu@ip-172-31-81-167:~$ sudo ls -ld /usr/bin/nmtui
-rwxr-xr-x 1 root root 751976 Jun  9  2022 /usr/bin/nmtui
```

After removing the SUID bit, the `/usr/bin/nmtui` file returns to its original permissions, and the SUID bit is no longer set. The permission string is back to `-rwxr-xr-x`.

In this example, we demonstrated how to set and remove the SUID bit on the `/usr/bin/nmtui` executable file using `chmod`. The SUID bit allows the file to temporarily run with the privileges of its owner, which can be useful for certain system utilities that require elevated access.

* **SGID (Set Group ID):**
    
    SGID is a special permission in Linux that can be applied to directories and executable files. When applied to a directory, SGID allows newly created files and directories within it to inherit the group ownership of the parent directory rather than the group of the user creating them. For executable files, the SGID permission works similarly to the SUID permission, but instead of running with the owner's privileges, it runs with the group's privileges.
    
    Now, let's break down the provided example:
    
    1. **Attempt to set the SGID bit without superuser privileges (fails):**
        
    
    ```bash
    ubuntu@ip-172-31-81-167:~$ chmod g+s chennai/
    chmod: changing permissions of 'chennai/': Operation not permitted
    ```
    
    The command `chmod g+s` tries to set the SGID bit for the "chennai/" directory but fails because regular users do not have the permission to set the SGID bit on directories they don't own.
    
    1. **Set the SGID bit using sudo (succeeds):**
        
    
    ```bash
    ubuntu@ip-172-31-81-167:~$ sudo chmod g+s chennai/
    ```
    
    By using `sudo`, we elevate our privileges and successfully set the SGID bit for the "chennai/" directory.
    
    1. **List details of the directory after setting SGID:**
        
    
    ```bash
    ubuntu@ip-172-31-81-167:~$ ls -ld chennai/
    drwxrwsr-x+ 2 Mahi CSK 4096 Jul 20 22:46 chennai/
    ```
    
    Now, the "chennai/" directory has the SGID bit set. The permission string shows "drwxrwsr-x", where the 's' in the group section indicates the SGID bit is set.
    
    1. **Enter the directory and create files as a regular user:**
        
    
    ```bash
    ubuntu@ip-172-31-81-167:~$ cd chennai/
    ubuntu@ip-172-31-81-167:~/chennai$ sudo touch file1.txt
    ```
    
    As a regular user, we create "file1.txt" inside the "chennai/" directory. Since the directory has the SGID bit set, the newly created file inherits the group ownership of the "chennai/" directory (CSK group).
    
    1. **List files in the directory and view permissions:**
        
    
    ```bash
    ubuntu@ip-172-31-81-167:~/chennai$ ll
    total 8
    drwxrwsr-x+  2 Mahi   CSK    4096 Jul 20 22:46 ./
    drwxr-x---  10 ubuntu ubuntu 4096 Jul 20 22:36 ../
    -rw-r--r--   1 root   CSK       0 Jul 20 22:48 file1.txt
    -rw-r--r--   1 root   root      0 Jul 20 22:46 file2.txt
    ```
    
    We can see that "file1.txt" was created with group ownership set to CSK, just like the parent directory, due to the SGID bit.
    
    1. **Attempt to remove the SGID bit without superuser privileges (fails):**
        
    
    ```bash
    ubuntu@ip-172-31-81-167:~$ chmod g-s chennai/
    chmod: changing permissions of 'chennai/': Operation not permitted
    ```
    
    The command `chmod g-s` tries to remove the SGID bit from the "chennai/" directory but fails because regular users don't have permission to remove the SGID bit from directories they don't own.
    
    1. **Remove the SGID bit using sudo:**
        
    
    ```bash
    ubuntu@ip-172-31-81-167:~$ sudo chmod g-s chennai/
    ```
    
    With `sudo`, we remove the SGID bit from the "chennai/" directory.
    
    1. **List details of the directory after removing SGID:**
        
    
    ```bash
    ubuntu@ip-172-31-81-167:~$ ls -ld chennai/
    drwxrwxr-x+ 2 Mahi CSK 4096 Jul 20 22:44 chennai/
    ```
    
    After removing the SGID bit, the "chennai/" directory returns to its original permissions, and the SGID bit is no longer set. The permission string shows "drwxrwxr-x".
    
    In this example, we demonstrated how to set and remove the SGID bit on the "chennai/" directory using `chmod`. The SGID bit allows newly created files and directories inside "chennai/" to inherit the group ownership of the parent directory, ensuring efficient group collaboration and control over shared files.
    
* **Sticky Bit:**
    
    The Sticky Bit is a special permission in Linux that can be applied to directories. When the Sticky Bit is set on a directory, only the owner of a file within that directory (or the root user) can delete or rename the file, even if other users have write permissions on that directory. This ensures that users can only delete or modify their own files within a shared directory.
    
    Now, let's break down the provided example:
    
    1. **Create a directory and make it world-writable:**
        
    
    ```bash
    root@ip-172-31-81-167:~# mkdir /data
    root@ip-172-31-81-167:~# ls -ld /data
    drwxr-xr-x 2 root root 4096 Jul 20 22:54 /data
    root@ip-172-31-81-167:~# chmod 777 /data
    root@ip-172-31-81-167:~# ls -ld /data
    drwxrwxrwx 2 root root 4096 Jul 20 22:54 /data
    ```
    
    We create a directory "/data" and set its permissions to "777" using `chmod`, making it world-writable.
    
    1. **Add a new user "sara" and switch to "rohit":**
        
    
    ```bash
    root@ip-172-31-81-167:~# useradd -m sara
    root@ip-172-31-81-167:~# su rohit
    ```
    
    We add a new user "sara" using `useradd` and switch to the existing user "rohit" using `su`.
    
    1. **Create files "r1," "r2," and "r3" in "/data" as "rohit" and "sara":**
        
    
    ```bash
    $ cd /data
    $ ls
    $ touch r1 r2 r3
    $ ls
    r1  r2  r3
    $ exit
    root@ip-172-31-81-167:~# su sara
    $ cd /data
    $ ls
    r1  r2  r3
    $ touch s1 s2 s3
    $ ls
    r1  r2  r3  s1  s2  s3
    $ exit
    ```
    
    We switch to the "rohit" user and create "r1," "r2," and "r3" files inside "/data." Then, we switch to the "sara" user and create "s1," "s2," and "s3" files inside "/data."
    
    1. **Set the Sticky Bit on "/data":**
        
    
    ```bash
    root@ip-172-31-81-167:~# chmod o+t /data
    root@ip-172-31-81-167:~# ls -ld /data
    drwxrwxrwt 2 root root 4096 Jul 20 22:57 /data
    ```
    
    We use `chmod` to set the Sticky Bit (indicated by "t" at the end of the permissions) on the "/data" directory. Now, the permission string is "drwxrwxrwt."
    
    1. **Try to delete files from "/data" as "rohit" (doesn't work):**
        
    
    ```bash
    root@ip-172-31-81-167:~# su rohit
    $ cd /data
    $ rm -rf s*
    rm: cannot remove 's1': Operation not permitted
    rm: cannot remove 's2': Operation not permitted
    rm: cannot remove 's3': Operation not permitted
    $ rm -rf *
    rm: cannot remove 's1': Operation not permitted
    rm: cannot remove 's2': Operation not permitted
    rm: cannot remove 's3': Operation not permitted
    $ ls
    s1  s2  s3
    $ exit
    root@ip-172-31-81-167:~# chmod o-t /data
    ```
    
    As "rohit," we try to delete "s1," "s2," and "s3" files using "rm -rf," but the operation is not permitted due to the Sticky Bit.
    
    The Sticky Bit ensures that users can only delete or modify files they own within the "/data" directory, preventing accidental deletion or tampering of other users' files in shared directories.
    
    1. **After removing the Sticky Bit, user 'rohit' can delete files:**
        
    
    ```bash
    root@ip-172-31-81-167:~# su rohit
    $ cd /data
    $ ls
    s1  s2  s3
    $ rm -rf *
    $ ls
    $ exit
    ```
    
    After removing the Sticky Bit, user 'rohit' can now delete all files within the '/data' directory.
    
    In this example, we demonstrated how to set and remove the Sticky Bit on the '/data' directory. With the Sticky Bit set, only the owner (or the superuser) can delete or rename their own files within the directory, promoting a secure and shared environment.
    

I hope you found this blog on "Linux Permissions" informative and helpful. 🧠🐧 By grasping the concepts of SUID, SGID, and the Sticky Bit, you can better manage file permissions, enhance security, and foster collaboration within your Linux environment. 🔒🤝 If you have any questions or feedback, feel free to reach out. I hope you like my blog! 🤗 Happy Linuxing! 🎉🐧