Common scenarios for special file permissions

Experimental Environment: Ubuntu 18.04 remote server + WSL 2 local machine

Evaluation Description#

[Version 1]

[Version 2]

⭐ Assess understanding of file permissions, especially file special permissions
- File permissions: Refer to the "Introduction to Linux and Usage" notes - Users and Groups and Modifying File Permissions
- File special permissions: Refer to the "Introduction to Linux and Usage" notes - Special Permissions for Files
Once you understand the above, implementing the above functionalities will be easy

Final Result#

Other users cannot enter the Project directory
TestUser1 created the file u1.txt
TestUser2 can still edit u1.txt, but cannot delete it
- Similarly for the reverse case

Implementation Process#

Preparation#

Create a user group called TestGroup using the groupadd command, there are some options available in the man manual to view

groupadd TestGroup

Create two users, TestUser1 and TestUser2, belonging to the TestGroup group

useradd -G TestGroup TestUser1
useradd -G TestGroup TestUser2

- The group needs to be created first
Set passwords for the users to log in, otherwise they won't be able to log in

passwd TestUser1
--->Enter password: xxx
passwd TestUser2
--->Enter password: yyy

Create a Project directory under /opt as the project directory

cd /opt
mkdir Project

Implementing Functionality 1 - Access Permissions#

[Only TestUser1, TestUser2, and root users can enter this directory]

Change the group ownership of the Project directory to TestGroup, leaving the user ownership unchanged

sudo chown :TestGroup Project

Remove the execute permission for other users, so that they cannot enter the directory

sudo chmod o-x Project

The result is as follows:

Implementing Functionality 2 - Editing Permissions#

[TestUser2 can edit files created by TestUser1]

First, add write permission to the TestGroup group, so that users can create files in this directory

sudo chmod g+w Project

Set the setgid bit, so that operations performed by users inside the directory will be done with the identity of the group that the directory belongs to

sudo chmod g+s Project

[PS] Otherwise, files created by users will belong to a group with the same name as the user, instead of TestGroup [thus the two users cannot establish a connection]

The permissions are as follows:

Implementing Functionality 3 - Deletion Permissions#

[TestUser1 and TestUser2 can only delete files created by themselves]

Set the sticky bit, so that users can only delete their own content in this directory

sudo chmod +t Project

The permissions are as follows:

[PS] The folder colors have changed, zsh did a great job

Points to Consider#

Scenario: A user who has no write permission for a file in a directory can still delete the file, why?
- The permission to delete a file depends on the user's permission to enter the directory
  - This user belongs to the TestGroup and has write permission
  - Refer to The Importance of Permissions for Directories in "The Linux Beginner's Guide" - Permissions for directories:
    - However, things are different when the sticky bit is involved

Additional#

The executable permission for a directory represents the permission to enter the directory

References#

"Introduction to Linux and Usage" - Users and Groups and Modifying File Permissions
"Introduction to Linux and Usage" - Special Permissions for Files
The Importance of Permissions for Directories by "The Linux Beginner's Guide"