In Linux systems, file permissions follow a strict hierarchy, but there's a particular case where non-root users can delete root-owned files that often surprises administrators:

$ ls -ld ~/temp
drwxrwxr-x. 2 cbennett cbennett 4096 Oct  5 20:59 /home/cbennett/temp

$ sudo touch ~/temp/rootfile
$ ls -l ~/temp/rootfile
-rw-r--r--. 1 root root 0 Oct  5 21:00 /home/cbennett/temp/rootfile

$ rm ~/temp/rootfile
rm: remove write-protected regular empty file 'rootfile'? y

The key lies in directory permissions, not the file permissions themselves. In Linux, the ability to delete a file depends on:

• Write permission on the containing directory (not the file)
• Execute permission on all path components

In your case, the directory permissions are drwxrwxr-x, meaning:

d - directory
rwx - owner (cbennett) has read/write/execute
rwx - group has read/write/execute
r-x - others have read/execute

This behavior has important security implications:

# Dangerous practice:
$ sudo chmod 777 /home/user/uploads

# Better alternative for shared directories:
$ sudo chown user:group /home/user/uploads
$ sudo chmod 2770 /home/user/uploads  # With setgid bit

For directories that need to protect files from arbitrary deletion (like /tmp), Linux provides the sticky bit:

$ ls -ld /tmp
drwxrwxrwt. 10 root root 4096 Oct  5 22:00 /tmp

# Setting sticky bit on a directory:
$ chmod +t /path/to/directory

Here's how to properly set up a shared directory with proper permissions:

# Create shared directory
$ sudo mkdir /shared
$ sudo groupadd project-team
$ sudo usermod -aG project-team user1
$ sudo usermod -aG project-team user2

# Configure permissions
$ sudo chown root:project-team /shared
$ sudo chmod 2770 /shared  # setgid + rwx for group

# Verification
$ ls -ld /shared
drwxrws---. 2 root project-team 4096 Oct  5 22:10 /shared

For more granular control, consider using Access Control Lists:

# Set default ACL for new files
$ sudo setfacl -d -m u:root:rwx /protected-dir
$ sudo setfacl -m u:root:rwx /protected-dir

# View ACL settings
$ getfacl /protected-dir

---

While performing server maintenance today, I encountered an interesting permission scenario that seems counterintuitive at first glance. As a regular user (cbennett), I was able to delete a file owned by root in my home directory, despite not having root privileges. Let's examine why this happens and what it means for Linux system security.

Here's how I reproduced the behavior:

[cbennett@nova ~/temp]$ ls -al
total 8
drwxrwxr-x.  2 cbennett cbennett 4096 Oct  5 20:59 .
drwxr-xr-x. 22 cbennett cbennett 4096 Oct  5 20:58 ..
-rw-rw-r--.  1 cbennett cbennett    0 Oct  5 20:58 my-own-file
[cbennett@nova ~/temp]$ sudo touch file-owned-by-root
[cbennett@nova ~/temp]$ ls -al
total 8
drwxrwxr-x.  2 cbennett cbennett 4096 Oct  5 21:00 .
drwxr-xr-x. 22 cbennett cbennett 4096 Oct  5 20:58 ..
-rw-r--r--.  1 root     root        0 Oct  5 21:00 file-owned-by-root
-rw-rw-r--.  1 cbennett cbennett    0 Oct  5 20:58 my-own-file
[cbennett@nova ~/temp]$ rm file-owned-by-root
rm: remove write-protected regular empty file 'file-owned-by-root'? y
[cbennett@nova ~/temp]$ ls -al
total 8
drwxrwxr-x.  2 cbennett cbennett 4096 Oct  5 21:00 .
drwxr-xr-x. 22 cbennett cbennett 4096 Oct  5 20:58 ..
-rw-rw-r--.  1 cbennett cbennett    0 Oct  5 20:58 my-own-file

To understand this behavior, we need to look at how Linux handles file permissions at both the file and directory level:

• File permissions (-rw-r--r--): Control read/write/execute access to the file contents
• Directory permissions (drwxrwxr-x): Control who can list, create, or remove files within the directory

The crucial factor here is the directory's write permission (drwxrwxr-x). The 'w' bit for the owner (cbennett) means:

drwxrwxr-x
 |||||
 ||||+-- Others: read & execute
 |||+--- Group: read, write & execute
 ||+---- Owner: read, write & execute
 |+----- Directory flag
 +------ File type (d for directory)

Since I own the directory and have write permissions, I can:

1. Add new files to the directory
2. Remove existing files from the directory
3. Rename files within the directory

If we want to prevent this behavior, we can use the sticky bit on directories (common for /tmp):

chmod +t directory_name
# Or
chmod 1775 directory_name

This would require users to either:

• Be the owner of the file
• Be the owner of the directory
• Have root privileges

This behavior is actually by design and makes sense when you consider:

1. The directory owner maintains control over their own space
2. Root-created files in user directories shouldn't permanently lock users out of managing their own directory structure
3. This allows for temporary files created by privileged processes to be cleaned up by users

Here's how different permission combinations would affect the ability to delete files:

# Case 1: Default home directory permissions (can delete)
drwxr-xr-x  2 user user 4096 Oct  5 21:00 .
-rw-r--r--  1 root root    0 Oct  5 21:00 testfile

# Case 2: Sticky bit prevents deletion
drwxr-xr-t  2 user user 4096 Oct  5 21:00 .
-rw-r--r--  1 root root    0 Oct  5 21:00 testfile

# Case 3: Directory not owned by user (can't delete)
drwxr-xr-x  2 root root 4096 Oct  5 21:00 .
-rw-r--r--  1 root root    0 Oct  5 21:00 testfile

To maintain proper security while allowing this expected behavior:

• Regularly audit directory permissions in user home directories
• Consider using ACLs for more granular control when needed
• Educate users about proper file permission management
• Use sticky bits on shared directories where appropriate