Did you know that users in a Linux system can change their own password using passwd even though they do not have write permission to edit the /etc/shadow file, the location of users passwords? This is possible because passwd has special permissions that gives any non-admin user root permissions during the execution of the command. The explanation lies in understanding Linux UIDs.

Whether you're a seasoned Linux user or just starting, understanding these process permissions, especially the role of SUID, is crucial for securing a Linux system in which you are inviting users inside.

First, let's demystify the concept of SUID - Set User ID. SUID is a special type of file permission given to a file in Linux systems. It allows users to execute the file with the permissions of the file owner rather than the user who is running it. This is particularly useful for allowing users to perform specific tasks that normally only the file owner, often the root user, can perform.

One can see the SUID by noticing the s:

$ stat /usr/bin/passwd
Access: (4755/-rwsr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)

The s indicates that any other user can execute passwd with the file owner’s permissions during execution time. In this case, the owner is root.

With this foundation, let's explore the three types of User IDs (UIDs) associated with Linux processes:

1. Effective User ID: This UID determines the access rights of a process. When you launch a process, it typically inherits the permissions of the user or group that initiated it. For instance, if Alice runs the touch command, the process operates with her permissions, and any files created are owned by her.

2. Real User ID: This is the ID of the user who actually launched the process. It serves as a way to identify the true initiator of a process, acting like a digital signature.

3. Saved User ID: This is where SUID comes into play. The Saved User ID allows a process to switch between the effective and real UID. This is crucial for maintaining security, as it limits the use of higher privileges only to specific instances where they are necessary.

Now, let's see how these concepts play out with the passwd command:

Suppose you use the passwd command with your user ID, say 1020. Normally, your effective UID would also be 1020. However, the passwd command is special because it has the SUID permission set. So, when you run it, your effective UID temporarily becomes 0, the root user's UID. This temporary elevation allows the program to access sensitive files and perform tasks like changing passwords, which are typically restricted to the root user.

But what if you decide to change another user's password, say John, who has a UID of 1022? Here, the system's design keeps things secure. Despite your temporary root powers, the process knows your real UID is 1020, not 1022, so you're not allowed to change John's password unless you're the superuser.

When running passwd, it starts with your real UID and also recognizes the effective UID (the file owner's UID, which is root in this case), enabling a switch between the two as needed. This system ensures that root access is not used more than necessary, maintaining a balance between functionality and security.

In most cases, your real UID and effective UID are the same. However, in situations involving SUID, like with the passwd command, they can differ. This difference is a key aspect of Linux's security model, which is ensuring that elevated privileges are used in a secure manner.

Understanding these mechanisms in Linux not only helps in performing administrative tasks but also in hardening your system when multiple users need to use it.

Thank you for reading!