Setuid

The Unix access rights flags setuid and setgid (short for "set user ID" and "set group ID") allow users to run an executable with the file system permissions of the executable's owner or group respectively and to change behaviour in directories. They are often used to allow users on a computer system to run programs with temporarily elevated privileges in order to perform a specific task. While the assumed user id or group id privileges provided are not always elevated, at a minimum they are specific.
The flags codice_1 and codice_2 are needed for tasks that require different privileges than what the user is normally granted, such as the ability to alter system files or databases to change their login password. Some of the tasks that require additional privileges may not immediately be obvious, though, such as the codice_3 command, which must send and listen for control packets on a network interface.
Effects.
The codice_1 and codice_2 flags have different effects, depending on whether they are applied to a file, to a directory or binary executable or non binary executable file. The codice_1 and codice_2 flags have an effect only on binary executable files and not on scripts (e.g., Bash, Perl, Python).
When set on an executable file.
When the codice_1 or codice_2 attributes are set on an executable file, then any users able to execute the file will automatically execute the file with the privileges of the file's owner (commonly root) and/or the file's group, depending upon the flags set. This allows the system designer to permit trusted programs to be run which a user would otherwise not be allowed to execute. These may not always be obvious. For example, the ping command may need access to networking privileges that a normal user cannot access; therefore it may be given the setuid flag to ensure that a user who needs to ping another system can do so, even if their own account does not have the required privilege for sending packets. 
For security purposes, the invoking user is usually prohibited by the system from altering the new process in any way, such as by using codice_10, codice_11 or sending signals to it, to exploit the raised privilege, although signals from the terminal will still be accepted.
The codice_1 and codice_2 bits are normally set with the command codice_14 by setting the high-order octal digit to 4 for codice_1 or 2 for codice_2. "codice_17" will set both the codice_1 and codice_2 bits (4+2=6), making the file read/write/executable for the owner (7), and executable by the group (first 1) and others (second 1). When a user other than the owner executes the file, the process will run with user and group permissions set upon it by its owner. For example, if the file is owned by user codice_20 and group codice_21, it will run as codice_22 no matter who executes the file.
Most implementations of the codice_14 command also support finer-grained, symbolic arguments to set these bits. The preferably finer-grained mode is shown in the demonstration below as the "codice_24"
Security impact.
While the codice_1 feature is very useful in many cases, its improper use can pose a security risk if the codice_1 attribute is assigned to executable programs that are not carefully designed. Due to potential security issues, many operating systems ignore the codice_1 attribute when applied to executable "shell scripts".
The presence of codice_1 executables explains why the codice_29 system call is not available to non-root users on Unix. See limitations of codice_29 for more details.
When set on a directory.
Setting the codice_2 permission on a directory ("codice_32") causes new files and subdirectories created within it to inherit its group ID, rather than the primary group ID of the user who created the file (the owner ID is never affected, only the group ID).
Setting the codice_2 bit on existing subdirectories must be done manually, with a command such as codice_36
The codice_1 permission set on a directory is ignored on most UNIX and Linux systems. However FreeBSD can be configured to interpret codice_1 in a manner similar to codice_2, in which case it forces all files and sub-directories created in a directory to be owned by that directory's owner - a simple form of inheritance. This is generally not needed on most systems derived from BSD, since by default directories are treated as if their codice_2 bit is always set, regardless of the actual value. As is stated in codice_41, "When a new file is created it is given the group of the directory which contains it."
Examples.
Checking permissions.
Permissions of a file can be checked in octal form and/or alphabetic form with the command line tool codice_42
[ torvalds ~ ] $ stat -c "%a %A" ~/test/
1770 drwxrwx--T
SUID.
4701 on an executable file owned by 'root' and the group 'root'
A user named 'thompson' attempts to execute the file. The executable permission for all users is set (the '1') so 'thompson' can execute the file. The file owner is 'root' and the SUID permission is set (the '4') - so the file is executed as 'root'.
The reason an executable would be run as 'root' is so that it can modify specific files that the user would not normally be allowed to, without giving the user full root access.
A default use of this can be seen with the codice_43 binary file. codice_43 needs to modify codice_45 and codice_46 which store account information and password hashes for all users, and these can only be modified by the user 'root'.
[ thompson ~ ] $ stat -c "%a %U:%G %n" /usr/bin/passwd
4701 root:root /usr/bin/passwd
[ thompson ~ ] $ passwd
passwd: Changing password for thompson
The owner of the process is not the user running the executable file but the owner of the executable file
SGID.
2770 on a directory named 'music' owned by the user 'root' and the group 'engineers'
A user named 'torvalds' who belongs primarily to the group 'torvalds' but secondarily to the group 'engineers' makes a directory named 'electronic' under the directory named 'music'. The group ownership of the new directory named 'electronic' inherits 'engineers.' This is the same when making a new "file" named 'imagine.txt'
Without SGID the group ownership of the new directory/file would have been 'torvalds' as that is the primary group of user 'torvalds'.
[ torvalds ~ ] $ groups torvalds
torvalds : torvalds engineers
[ torvalds ~ ] $ stat -c "%a %U:%G %n" ./music/
2770 root:engineers ./music/
[ torvalds ~ ] $ mkdir ~/music/electronic
[ torvalds ~ ] $ stat -c "%U:%G %n" ./music/electronic/
torvalds:engineers ./music/electronic/
[ torvalds ~ ] $ echo 'NEW FILE' > ./music/imagine.txt
[ torvalds ~ ] $ stat -c "%U:%G %n" ./music/imagine.txt
torvalds:engineers ./music/imagine.txt
[ torvalds ~ ] $ touch ~/test
[ torvalds ~ ] $ stat -c "%U:%G %n" ~/test
torvalds:torvalds ~/test
Sticky bit.
1770 on a directory named 'videogames' owned by the user 'torvalds' and the group 'engineers'.
A user named 'torvalds' creates a file named 'tekken' under the directory named 'videogames'. A user named 'wozniak', who is also part of the group 'engineers', attempts to delete the file named 'tekken' but he cannot, since he is not the owner.
Without sticky bit 'wozniak' could have deleted the file, because the directory named 'videogames' allows read and write by 'engineers'. A default use of this can be seen at the codice_47 folder.
[ torvalds /home/shared/ ] $ groups torvalds
torvalds : torvalds engineers
[ torvalds /home/shared/ ] $ stat -c "%a %U:%G %n" ./videogames/
1770 torvalds:engineers ./videogames/
[ torvalds /home/shared/ ] $ echo 'NEW FILE' > videogames/tekken
[ torvalds /home/shared/ ] $ su - wozniak
Password:
[ wozniak ~/ ] $ groups wozniak
wozniak : wozniak engineers
[ wozniak ~/ ] $ cd /home/shared/videogames
[ wozniak /home/shared/videogames/ ] $ rm tekken
rm: cannot remove ‘tekken’: Operation not permitted
Sticky bit with SGID.
3171 on a directory named 'blog' owned by the group 'engineers' and the user 'root'
A user named 'torvalds' who belongs primarily to the group 'torvalds' but secondarily to the group 'engineers' creates a file or directory named 'thoughts' inside the directory 'blog'. A user named 'wozniak' who also belongs to the group 'engineers' cannot delete, rename, or move the file or directory named 'thoughts', because he is not the owner and the sticky bit is set. However, if 'thoughts' is a file, then 'wozniak' can edit it.
Sticky bit has the final decision. If sticky bit and SGID had not been set, the user 'wozniak' could rename, move, or delete the file named 'thoughts' because the directory named 'blog' allows read and write by group, and wozniak belongs to the group, and the default 0002 umask allows new files to be edited by group. Sticky bit and SGID could be combined with something such as a read-only umask or an append only attribute.
[ torvalds /home/shared/ ] $ groups torvalds
torvalds : torvalds engineers
[ torvalds /home/shared/ ] $ stat -c "%a %U:%G %n" ./blog/
3171 root:engineers ./blog/
[ torvalds /home/shared/ ] $ echo 'NEW FILE' > ./blog/thoughts
[ torvalds /home/shared/ ] $ su - wozniak
Password:
[ wozniak ~/ ] $ cd /home/shared/blog
[ wozniak /home/shared/blog/ ] $ groups wozniak
wozniak : wozniak engineers
[ wozniak /home/shared/blog/ ] $ stat -c "%a %U:%G %n" ./thoughts
664 torvalds:engineers ./thoughts
[ wozniak /home/shared/blog/ ] $ rm thoughts
rm: cannot remove ‘thoughts’: Operation not permitted
[ wozniak /home/shared/blog/ ] $ mv thoughts /home/wozniak/
mv: cannot move ‘thoughts’ to ‘/home/wozniak/thoughts’: Operation not permitted
[ wozniak /home/shared/blog/ ] $ mv thoughts pondering
mv: cannot move ‘thoughts’ to ‘pondering’: Operation not permitted
[ wozniak /home/shared/blog/ ] $ echo 'REWRITE!' > thoughts
[ wozniak /home/shared/blog/ ] $ cat thoughts
REWRITE!
Security.
Developers should design and implement programs that use this bit on executables carefully in order to avoid security vulnerabilities including buffer overruns and path injection. Successful buffer-overrun attacks on vulnerable applications allow the attacker to execute arbitrary code under the rights of the process exploited. In the event that a vulnerable process uses the codice_1 bit to run as codice_20, the code will execute with root privileges, in effect giving the attacker root access to the system on which the vulnerable process is running.
Of particular importance in the case of a codice_1 process is the environment of the process. If the environment is not properly sanitized by a privileged process, its behavior can be changed by the unprivileged process that started it. For example, GNU libc was at one point vulnerable to an exploit using codice_1 and an environment variable that allowed executing code from untrusted shared libraries.
History.
The codice_1 bit was invented by Dennis Ritchie and included in codice_53. His employer, then Bell Telephone Laboratories, applied for a patent in 1972; the patent was granted in 1979 as patent number . The patent was later placed in the public domain.