What is the real need of Saved User ID?

CONTEXT: While learning about the 3 different UIDs of users and processes — Real UID(RUID), Effective UID(EUID), Saved UID(SUID, not to be confused with setuserid bit), I wondered why do we even need SUID when we are just using it for storing the privileged id? Can’t the process simply make a system call to regain the owner’s privileges as needed?

Why Not Use a System Call?

The kernel needs a way to determine if a process requesting elevated privileges is genuinely allowed to regain them. If a process could make an arbitrary system call to restore privileges, there’d be no way for the kernel to confirm if it’s genuinely entitled to do so. The kernel has to store that information somewhere. It is as if the kernel needs some way to tell if a process was trustable enough to have already assigned privileged access previously and is requesting them again after dropping them mid-process….., feels familiar? It then clicked to me that SUID is like a security badge—if the kernel recognizes the badge, it knows the process was trusted enough to receive privileges before and can be trusted to regain them. After all, we wouldn’t have given it that access if we didn’t trust it, right…?

Ensuring Only Trusted Processes Escalate Privileges

So how do we ensure that only a trusted process gets the chance to escalate its privileges? Well, this can happen in three main ways:

1. Directly by Root: Running processes as root grants full access, but this is risky and not a recommended practice.

2. Using su or sudo: These tools require user authentication or validation against the sudoers list.

3. Using the setuid Bit: Executable files with the setuid bit set can run with elevated privileges if thoroughly evaluated and secured.

Only trusted processes can escalate privileges, and the SUID mechanism helps ensure that this trust is maintained.