Since normal users cannot write to /etc/passwd, you might be wonder how a normal user can change their password? The "passwd" program used to change passwords has to write to /etc/passwd after all.

When the passwd program executes, its real UID is that of the user who invoked it. However, its effective UID is that of the superuser. Thus, while passwd is executing, it has the privilege of the superuser. This is because passwd is a "set-UID" program owned by root. When a set-UID program runs, its effective UID is set to that of its owner and not to that of its invoker.

Many system programs are set-UID. For example, the login program has to have superuser privilege. It must set the real and effective UID of the user's new shell to the correct values. However, only superuser programs can change their real UID.

You can tell a program is set-UID because an (s) appears in its permission list where the (x) would appear. For example

Permissions    Owner     Group    Name
r-sr-xr-x      root      other    passwd

The (s) in the execute position for the owner means that passwd is a set-UID program. Notice that passwd is executable by everyone.

The set-UID feature is useful for non-superusers as well. For example, suppose I were to write a grade reading program that my students could execute to check my grade book. I don't want to grant read access to my grade book to just anyone. Thus I write a program that will only read the appropriate grades, and I make it set-UID owned by me. Thus when a student executes the program, they have the rights of me, and the program can read my grade book file on their behalf.

Similarly, programs can be set-GID. In that case, when they start executing, their effective GID is set to the group associated with the program and not the real GID of the invoker. For example, VTC3 could write a set-GID program that has the rights of the club but that could be executed by any user.

Set-GID programs are not as common as set-UID programs.