http://en.wikipedia.org/wiki/Setuid
setuid on executables
When a binary executable file has been given the setuid attribute, normal users on the system can execute this file and gain the privileges of the user who owns the file (commonly root) within the created process. When root privileges have been gained within the process, the application can then perform tasks on the system that regular users normally would be restricted from doing. The invoking user will be prohibited by the system from altering the new process in any way, such as by using ptrace, LD_LIBRARY_PATH or sending signals to it (signals from the terminal will still be accepted, however). Due to the increased likelihood of security flaws, many operating systems ignore the setuid attribute when applied to executable shell scripts.
While the setuid feature is very useful in many cases, it can pose a security risk if the setuid attribute is assigned to executable programs that are not carefully designed. Users can exploit vulnerabilities in flawed programs to gain permanent elevated privileges, or unintentionally execute a trojan horse program.
The setgid attribute will allow for changing the group based privileges within a process, like the setuid flag does for user based privileges.
The presence of setuid executables justifies the fact that the chroot system call is not available to non-root users on Unix.
The setuid and setgid bits are normally set with the command chmod by setting the high-order octal to 4 or 2 (or 6 to set both). chmod 6711 will set the setuid and setgid bit (6) make the file read/write/executable for the owner (7) and executable by the group and others (11). All chmod flags are octal, and the least significant bit of the high-order octal is used for a special mode known as the sticky bit.
Most implementations of the chmod command also support symbolic arguments to set these bits. This is shown in the demonstration below as the chmod ug+s command.
The demonstration C program below simply obtains and reveals the real and effective user and group id currently assigned to the process. The commands shown first compile the process as user bob and subsequently use chmod to establish the setuid and setgid bits. The su command, itself a client of the setuid feature, is then used to assume the id of alice. The effectiveness of the chmod command is checked with ls -l, and finally the demonstration program is run, revealing the expected identity change, consistent with the /etc/passwd file.
Note that the demonstration program listed below will silently fail to change the effective UID if run on a volume mounted with the nosuid option.
alice:x:1007:1007::/home/alice:/bin/bash
bob:x:1008:1008::/home/bob:/bin/bash
[bob@foo]$ cat printid.c
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
int main(void)
{
printf("Real UIDt= %dn", getuid());
printf("Effective UIDt= %dn", geteuid());
printf("Real GIDt= %dn", getgid());
printf("Effective GIDt= %dn", getegid());
return EXIT_SUCCESS;
}
[bob@foo]$ gcc -Wall printid.c -o printid
[bob@foo]$ chmod ug+s printid
[bob@foo]$ su alice
Password:
[alice@foo]$ ls -l
-rwsr-sr-x 1 bob bob 6944 2007-11-06 10:22 printid
[alice@foo]$ ./printid
Real UID = 1007
Effective UID = 1008
Real GID = 1007
Effective GID = 1008
[alice@foo]$[edit] setgid on directories
The setuid and setgid flags, when set on a directory, have an entirely different meaning.
Setting the setgid permission on a directory (chmod g+s) causes new files and subdirectories created within it to inherit its groupID, rather than the primary groupID of the user who created the file (the ownerID is never affected, only the groupID). Newly created subdirectories inherit the setgid bit. Note that setting the setgid permission on a directory only affects the groupID of new files and subdirectories created after the setgid bit is set, and is not applied to existing entities. Setting the setgid bit on existing subdirectories must be done manually, with a command such as the following:
find /path/to/directory -type d -print0 | xargs -0 chmod g+sor
[root@foo]# find /path/to/directory -type d -exec chmod g+s {} ;The setuid flag has no effect on the permission bits (drwxr-sr-x) of any directory or file. It affects only the numerical groupID (commonly represented as a group name).
The setuid permission set on a directory is ignored on UNIX and GNU/Linux systems [1]. FreeBSD can be configured to interpret it similarly to setgid, namely, to force all files and sub-directories to be owned by the top directory owner.[2]