Next: How an Application Can Change Persona, Previous: The Persona of a Process, Up: Users and Groups [Contents][Index]
The most obvious situation where it is necessary for a process to change
its user and/or group IDs is the login program. When
login starts running, its user ID is root. Its job is to
start a shell whose user and group IDs are those of the user who is
logging in. (To accomplish this fully, login must set the real
user and group IDs as well as its persona. But this is a special case.)
The more common case of changing persona is when an ordinary user program needs access to a resource that wouldn’t ordinarily be accessible to the user actually running it.
For example, you may have a file that is controlled by your program but that shouldn’t be read or modified directly by other users, either because it implements some kind of locking protocol, or because you want to preserve the integrity or privacy of the information it contains. This kind of restricted access can be implemented by having the program change its effective user or group ID to match that of the resource.
Thus, imagine a game program that saves scores in a file. The game
program itself needs to be able to update this file no matter who is
running it, but if users can write the file without going through the
game, they can give themselves any scores they like. Some people
consider this undesirable, or even reprehensible. It can be prevented
by creating a new user ID and login name (say, games) to own the
scores file, and make the file writable only by this user. Then, when
the game program wants to update this file, it can change its effective
user ID to be that for games. In effect, the program must
adopt the persona of games so it can write to the scores file.
Next: How an Application Can Change Persona, Previous: The Persona of a Process, Up: Users and Groups [Contents][Index]