UNIX real-UID, valid-UID and saved-UID

Real-UID:

• Real-UID is the ID of the user that launched a process.

Valid tive-UID:

• Valid-UID is usually the same as the real-UID. however, sometimes a user needs to access resources (like files) that they don't have ownership. if it requires such access, the specified tive-UID changes from its real-UID to the UID of the user who owns
  That resource.
• Valid tive-UID is used to evaluate privileges of the process to perform a participant action.
• If the specified tive-UID! = 0 (not root), valid-UID can be changed either to Real-UID, or saved-UID.
• If the specified tive-uid = 0 (Root), it can be changed to anything.
• Most of the time, the kernel checks only the valid tive-UID. for example, if a process tries to open a file, the kernel checks the valid tive-UID when deciding whether to let the process access the file. if the kernel cares about only the valid user ID,
  It doesn' t seem like there is much point in having a distinction between a real-UID and an alternative tive-UID. however, there is one very important case in which the real User ID matters. if you want to change the valid tive-UID of an already running process,
  Kernel looks at the real-UID as well as the valid tive-UID.

Saved uid:

• If you run an executable with the set-UID bit set, then the resulting running process will start with a real-UID of the real user running it, and an either tive-UID and saved-UID of the owner of the executable file. if the process then CILS "setuid" or "seteuid"
  To change their valid tive-UID, they can still get back their origin Al privileges again thanks to the saved-UID. if the set-UID bit is not set, saved-UID will be the real-UID.
• The saved-UID is there so a process can switch its valid tive-UID to its real-UID, then back again; otherwise it wocould be a one-way operation.

What is the idea?

At the lowest level of the Operating System (the kernel), users are not identified by names, but numbers called user IDs (UID). The user ID 0 is commonly called "root ".

Each UNIX process has a uid associated with it, and when trying to open a file for writing, for instance, this ID is used to determine whether the process shoshould be granted access or not.

When you invoke the "passwd" utility, the valid-UID of the process is set to 0, I. e. the UID of the root user. as a result, the program is permitted to modify the/etc/passwd file, and can thus replace the encrypted password in your account entry
The new one you just provided.

As a normal user, you're only allowed to modify the password of your own account using the "passwd" utility and it doesn' t let you modify the password of any other account. so now the question is, how does the program know who invoked the utility?

That is where another uid comes in, called the real-UID, which is used to track who the user really is. this real-UID value is not changed when you invoke programs such as "passwd ". so the program simply needs to find out what user name corresponds to its
Real-UID, and refuse to change any other account.

Normal programs, like "ls", "cat" run by a normal user under that users real-UID. special programs that allow user to have controlled access to protected data, can have set-UID bit to allow the program to be run under privileged uid.

Example:

When a normal user (say "mhasan") runs the program "passwd", it starts:

Real-uid = mhasan
Valid tive-uid = mhasan
Saved-uid = root

The Program (passwd) Then calla system call "seteuid 'and since saved-uid = 0, the call will succeed and the UIDs will be:

Real-id = mhasan
Valid tive-uid = root
Saved-uid = root

After that, "passwd" process will be able to access/etc/passwd and Change Password for user "mhasan ".