Manage Special Permissions and umask in Linux

Introduction

In this lab, you will learn how to manage special permissions and the umask setting in a Linux environment to secure a collaborative workspace. You will explore how to control the default permissions assigned to newly created files and how to use special permission bits, such as the sticky bit, to protect files within a shared directory from being deleted by other users.

You will begin by preparing a simulated shared environment, which involves creating a new user group and a directory, then assigning appropriate ownership and permissions. You will then modify the umask value to enforce stricter default permissions and verify its effect by creating a new file. Finally, you will set the sticky bit on the shared directory and confirm its application, ensuring that only file owners can delete their own files within that shared space.

Prepare the Environment and Access the Directory

In this step, you will prepare the environment for managing special file permissions. This involves creating a dedicated directory that simulates a shared workspace for a research team. You will create a new user group, a directory, and then assign the appropriate ownership and permissions to it. All operations will be performed in your project directory, ~/project.

First, let's create a new group named research. This group will represent the team members who have access to the shared directory. Use the sudo groupadd command to create it. sudo is used because creating groups is an administrative task.

sudo groupadd research

Next, create a new directory named RandD inside your ~/project directory. This will be our main working directory for this lab.

mkdir ~/project/RandD

Now, change the group ownership of the newly created RandD directory to the research group. The chgrp command is used for this purpose.

sudo chgrp research ~/project/RandD

To ensure that only the owner (labex user) and members of the research group can access this directory, set its permissions. We will use the chmod command with the numeric code 770. This code grants read, write, and execute permissions (rwx, which is 4+2+1=7) to the user and the group, and no permissions (---, which is 0) to others.

chmod 770 ~/project/RandD

You can verify the directory's permissions and ownership using the ls -ld command. The -l option provides a long listing format, and the -d option lists the directory itself, not its contents.

ls -ld ~/project/RandD

You should see an output similar to this, confirming the permissions (drwxrwx---), owner (labex), and group (research).

drwxrwx--- 2 labex research 4096 Dec 12 10:30 /home/labex/project/RandD

Finally, change your current location to the RandD directory. This is where you will perform the tasks in the following steps.

cd ~/project/RandD

You have now successfully set up the working environment.

Restrict Default File Permissions with umask 027

In this step, you will learn how to control the default permissions for newly created files using the umask command. When you create a file, the system assigns it a default set of permissions. Often, these defaults are too permissive, for example, allowing "Other" users to read your files. In a secure environment like our RandD directory, we want to restrict this.

The umask (user file-creation mode mask) command specifies the permissions that should be removed from the base permissions when a new file or directory is created.

• For files, the base permission is 666 (rw-rw-rw-).
• For directories, the base permission is 777 (rwxrwxrwx).

We will set the umask to 027. This value tells the system to remove the following permissions:

• User (owner): 0 - No permissions removed.
• Group: 2 - Write permission removed.
• Other: 7 (4+2+1) - Read, write, and execute permissions removed.

This means any new file created will have permissions of 666 - 027 = 640 (rw-r-----), and any new directory will have permissions of 777 - 027 = 750 (rwxr-x---).

First, change the default permissions for your current terminal session by entering umask 027 at the shell prompt. Ensure you are still in the ~/project/RandD directory.

umask 027

Next, verify the new value of umask by entering the command by itself.

umask

The command should display the new umask value. The leading zero indicates that no special permissions (like the sticky bit, which you'll learn about later) are part of the mask.

027

You have now successfully changed the default file creation permissions for your current session. In the next step, you will create a file to observe the effect of this new umask.

Create a File and Verify the New umask Permissions

In this step, you will put the new umask setting into practice by creating a file. This will demonstrate how the default permissions you configured in the previous step are automatically applied, securing your new document from unauthorized access. You should still be in the ~/project/RandD directory.

Let's create a new, empty file named schedule.odt using the touch command. The touch command is a simple way to create empty files or update the timestamp of existing ones.

touch schedule.odt

Now that the file is created, you need to verify its permissions. Use the ls -l command to display the detailed information for schedule.odt.

ls -l schedule.odt

You will see an output similar to the following. The most important part is the first column, which shows the file's permissions.

-rw-r----- 1 labex research 0 Dec 12 10:35 schedule.odt

Let's break down the permissions string -rw-r-----:

• The first character - indicates that this is a file.
• The next three characters rw- are the permissions for the user (owner), which are read and write. This corresponds to the numeric value 6.
• The next three characters r-- are the permissions for the group, which is read-only. This corresponds to the numeric value 4.
• The last three characters --- are the permissions for other, meaning no permissions at all. This corresponds to the numeric value 0.

These permissions (640) are the direct result of applying the umask of 027 to the system's default file permissions of 666. The umask successfully removed write permissions for the group and all permissions for others, just as we intended.

Set the Sticky Bit on a Directory with chmod 1771

In this step, you will address a common issue in shared directories. Currently, any member of the research group can delete any file within the ~/project/RandD directory, even files created by other users. This is because write permission on a directory allows for file creation and deletion. To prevent accidental or malicious deletions, you will set a special permission known as the "sticky bit".

The sticky bit, when applied to a directory, modifies this behavior. It ensures that a file within the directory can only be deleted or renamed by the file's owner, the directory's owner, or the root user. This is ideal for collaborative environments like our RandD directory.

You will use the chmod command with a four-digit octal number to set the sticky bit. The command will be chmod 1771 RandD.

• The first digit, 1, represents the sticky bit.
• The following three digits, 771, set the standard permissions: rwx for the user, rwx for the group, and --x for others.

First, you need to be in the parent directory of RandD to modify its permissions. Since you are currently in ~/project/RandD, use the cd .. command to move up one level to ~/project.

cd ..

Now, from the ~/project directory, apply the sticky bit to the RandD directory.

chmod 1771 RandD

The sticky bit is now set on the RandD directory. In the final step, you will use the ls -l command to see how this special permission is displayed and verify its effect.

Verify the Sticky Bit Permission with ls -l

In this final step, you will verify that the sticky bit was correctly applied to the RandD directory. The ls -l command provides a visual indicator for special permissions like the sticky bit. You should still be in the ~/project directory.

At the shell prompt, enter the ls -ld RandD command to view the permissions of the directory itself.

ls -ld RandD

Examine the output carefully. It should look similar to this:

drwxrwx--t 2 labex research 4096 Dec 12 10:45 RandD

The key change is in the permissions string: drwxrwx--t.

• The d indicates it's a directory.
• rwx shows the user (labex) has full permissions.
• The second rwx shows the research group has full permissions.
• The final part, --t, is where the sticky bit is shown. The t replaces what would normally be the execute permission (x) for "other". A lowercase t indicates that both the sticky bit and the execute permission for "other" are set. This confirms that your chmod 1771 command was successful.

Congratulations! You have successfully configured a shared directory with secure default permissions using umask and protected its contents from unauthorized deletion by setting the sticky bit.

Summary

In this lab, you learned to prepare a secure, shared directory for a user group. This involved creating a new group with groupadd, making a directory, and then using chgrp and chmod to assign the correct group ownership and restrictive permissions (770). You also practiced manipulating the default permissions for newly created files and directories by setting a specific umask value (027), and then verified its effect by creating a new file and inspecting its permissions.

Furthermore, you explored special permissions by applying the sticky bit to the shared directory using the command chmod 1771. You learned that the sticky bit is essential for collaborative environments, as it ensures that users can only delete or rename files that they personally own, preventing accidental or malicious removal of others' work. Finally, you verified that the sticky bit was correctly applied by using ls -l and identifying the t in the directory's permission string.