Setuid is an API available on many Unix type operating systems, including the Linux OS. It is used to change the effective user ID of an executing process, to alter the access the program has within the system.
Unix-type OS'es use the concept of role-based permissions, wherein what one can do on a system depends on who you are, and what type of user you are.
Who you are is determined by your user ID, which is usually seen to you as a name (much like your E2 user ID). To the underlying operating system, who you are is, alas, just one more number. This number is your UID, user ID.
What type of user you are is determined by what group you belong in. Just like high school, in a way. Your group is given a number, called the GID, or group ID.
This system has a number of nice benefits. The OS has the ability to restrict access to files based on your user ID number. So, I can make sure that I can read and write to my secret journal of nefarious deeds, but that no-one else (with the exception of root or the superuser) can read it. Alternatively, I can give access to a certain group, perhaps to allow someone to collaborate with me, giving them write access to a select number of files based on GID. Or I can publish, letting the whole world read my web diary, but allowing only me to write to it. You get the idea.
Where a problem emerges is when you realize that I need to have access to from time to time, that I really don't need all the time, and maybe shouldn't have. The classic example is the password file. To save administrative headaches, and to improve security, I need to be able to change my own password without having to go through an intermediary. This means that I need to have write access to the file that stores the passwords, or their representation to the system. Well, say I'm not the nice guy that I am, and while I'm there I decide to change the passwords for everyone else in the system, or give myself access to restricted files. An uh-oh has just occured.
What, then, can we do? Well, one solution is to decentralize the password file. Everyone has their own password file, which the computer reads in order to authenticate you. Well, now instead of having one password file to secure, we may have several thousand. We also have a chicken and the egg problem- I need access to my account to be authenticated, but I must be authenticated in order to access my account. Keep in mind that every single program on a Unix type system must be running on behalf of someone- their must be a user ID associated with every single process. And every program I run, in the simple model, must use my user ID.
So setuid enhances the simple model. It says, here write a program that will run with a user ID other than that of the person running the program. The setuid API does just that, changes the effective user ID with which a program executes. Now, the password changing program is the 'user' that owns the password file. When I run the program, the setuid command causes it to run as the password program user, not as whatever my UID is. This means that when I need to change my password, I can invoke the program without I myself having write access to the password file. The program can also act as an intermediary, and ensure that I only change the entry that belongs to me in the file. Problem solved.
Unfortunately, in a rather trite bit of melodrama, the problems are just beginning. We've solved the problem of users needing partial access to restricted files through the use of setuid. But now, we have numerous programs running around on our computer that have access to files and resources that we don't want users to have. This means that there are still significant vulnerabilities. What happens when such a program crashes? It may just dump the user out of the operation they were performing. But it may leave the restricted file in an unknown state, or allow access to it by someone who shouldn't have it. Worse yet, particularly if the program is running setuid root, a program failure may dump the user to a shell with the effective UID of the program, allowing a malicious or inane user to cause some serious trouble. As such, writing secure setuid programs is a challenge, and they have been a source of numerous security problems over the years.
As such, setuid programs are typically written with access to the smallest pool of resources they need to get the job done, but no more. Creating a UID that is used only for running a particular setuid program is a common practice along this vein. The programmer may also try to ensure that the program drops some or all of its privileges before invoking another process on its behalf, where possible. Another security measure is to invoke chroot on a setuid program, to try to ensure that if the security of the program is violated, the potential damage to the system can be limited and isolated.