Why Does the rm Command Allow the Deletion of Files Owned by Another User?

1. Overview

In Linux, the rm command stands as a powerful tool for file deletion. One might wonder, however, why rm is allowed to delete a file under the ownership of a different user.

In this tutorial, we’ll delve into the intricacies of Linux file management, permissions, and the role of the rm command in file deletion. In addition, we’ll explore the reasons behind this seemingly counterintuitive behavior and shed light on how symbolic and hard links, as well as different permission sets, play a role in this process.

2. Understanding Ownership and Permissions

Before diving into the specifics of rm, let’s understand the concepts of ownership and permissions in the Linux file system. Each file and directory is associated with an owner and a group, both with specific permissions – read, write, and execute – assigned to them. Furthermore, users can belong to multiple groups, and these permissions dictate who can perform what actions on a file or directory.

2.1. Changing Ownership

To check the user and group assigned to a certain file, we use the ls -l command:

$ ls -l file.txt
-rw-r--r-- 1 user1 developers 1024 Feb 4 10:00 file.txt

In the above command, we can see that file.txt belongs to the user user1 and developers group.

In case we need to change the ownership of file.txt from user1 to user2, we can utilize the chown command:

$ sudo chown user2:developers file.txt
$ ls -l file.txt
-rw-r--r-- 1 user2 developers 1024 Feb 4 10:00 file.txt

As we can see from the output above, the owner of file.txt is now shown as user2. Before that, we need to make sure we’re logged in as the root user. However, since we aren’t logged in as root, we made use of the sudo command to grant us superuser privileges to be able to apply the chown command.

2.2. Changing User Permissions

After we understood how to change the ownership for a specific file, let’s learn how to change the permissions assigned for a specific user regarding a specific file.

At first, to change the permissions using the numeric representation for a certain user, our only concern is the first digit after the chmod command. Nevertheless, if we’re trying to change group permissions, we’ll deal with the second digit only. Finally, in case we’re looking to change the other permissions, we’ll look into the third digit.

Next, let’s add the write permission for group developers on file.txt:

$ sudo chmod 664 file.txt
$ ls -l file.txt
-rw-rw-r-- 1 user2 developers 1024 Feb 4 10:00 file.txt

The system has now applied the new permissions to file.txt. In addition, we can apply the same changes for a directory by typing the directory name instead of the file name.

3. Understanding the Illusion of File Control

We can imagine a file as a locked box, in which the owner holds the key, but access isn’t solely determined by ownership. Particularly, permission levels, read, write, and execute, act as gatekeepers for both the file itself and the directory it resides in:

• file permissions: dictate who can peek, modify, or run the file’s contents
• directory permissions: govern who can list, create, delete, or rename files within the directory

Accordingly, while owning a file grants control over its content, deleting it requires another crucial element: write permission to the directory it calls home.

3.1. Examining the Permission Landscape

To illustrate this, let’s create a file named secret.txt as a user named alice:

$ touch secret.txt
$ ls -l secret.txt
-rw-r--r-- 1 alice alice 0 Jul 31 15:40 secret.txt

Here, we used the command touch to create the file. Then, we create another user bob, and grant him write permissions to alice‘s home directory:

$ sudo useradd bob
$ sudo chown alice:bob /home/alice
$ sudo chmod o+w /home/alice

We used the command useradd to add a new user. Moreover, we modified the permissions for user bob over alice‘s home directory by utilizing o+w options. In essence, we enabled bob to list and create files in the directory, but he can’t modify secret.txt due to its file permissions.

3.2. Exploring Directory Permissions

Now, let’s try to delete secret.txt as user bob:

$ su - bob
$ rm /home/alice/secret.txt

In this example, we used the su command to switch to user bob.

Shockingly, the deletion succeeds! Why? Because even though bob doesn’t own the file, he has write permission to the directory /home/alice, enabling him to remove the file entry from that directory. Finally, this highlights the key takeaway: deleting a file requires write permission to the directory, not necessarily ownership of the file itself.

4. Risk Mitigation

Now that we understand the “why,” let’s explore the “how” to prevent unauthorized file deletion.

4.1. Restrict Directory Permissions

Let’s try to delete the same file after limiting write access to user bob to the specified directory:

$ sudo chmod o-w /home/alice
$ rm /home/alice/secret.txt
$ ls -l /home/alice
drwxr-x--- 2 alice alice 4096 Jul 31 15:40 alice

Consequently, we notice that the delete operation has failed. As we might interpret from the output of the ls command, only the user alice has read, write, and execute permissions, while others only have read and execute permissions, preventing them from writing and deleting files.

Moreover, we need to make sure not to grant unnecessary sudo access. In other words, we shall use regular user accounts for everyday tasks. In essence, this minimizes the potential damage from accidental or malicious use of superuser privileges.

4.2. Sticky Bit Protection

Another proactive mitigation is to set the sticky bit on directories:

$ sudo chmod +t /home/alice
$ ls -l /home/alice
drwxr-x--t 2 alice alice 4096 Jul 31 15:40 alice

In this output, the t  indicates the sticky bit is set. Now, even if bob gains write permission to the directory, he can’t delete or rename files owned by alice. Remarkably, this prevents non-owners from deleting or renaming files within a certain directory.

4.3. Using Hard Links

While mv to a trash directory offers basic recovery, hard links can provide even stronger protection. In particular, hard links are great aliases for the same file data. Hence, instead of outright deletion, we can consider creating a hard link of the “to-be-deleted” files or important ones and then removing the original.

Let’s create a hard link to secret.txt:

$ sudo ln secret.txt secret_backup.txt
$ rm secret.txt

Now, both links point to the same inode that holds the raw data of the file. In this scenario, even if someone with write access to the directory deletes the original secret.txt file, the data persists through the secret_backup.txt link. Notably, deleting all hard links removes the data permanently.

By understanding these nuances, we can leverage links strategically to create secure backdoors against accidental or unauthorized deletion.

5. Conclusion

In this article, we learned that the rm command’s ability to delete files owned by different users depends on the underlying concepts of ownership, permissions, and the manipulation of inodes.

We also got an understanding of hard links, as well as the intricacies of permission sets. Moreover, we got clarity on this seemingly unconventional behavior.

Finally, we understood that the Linux file management system offers a robust and flexible environment, allowing users to navigate and control their data while maintaining security measures.