setuid and setgid (short for "set user ID upon execution" and "set group ID upon execution", respectively)[1] are Unix access rights flags that allow users to run an executable with the permissions of the executable's owner or group. 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.
setuid and setgid are needed for tasks that require higher privileges than those which common users have, such as changing their login password.[2] Some of the tasks that require elevated privileges may not immediately be obvious, though — such as the ping command, which must send and listen for control packets on a network interface.
Contents |
setuid on executablesWhen an executable file has been given the setuid attribute, normal users on the system who have permission to execute this file gain the privileges of the user who owns the file (commonly root) within the created process.[2] 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 potential race conditions,[3] many operating systems ignore the setuid attribute when applied to executable shell scripts.
While this setuid feature is very useful in many cases, its improper use can pose a security risk[2] 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 explains why the chroot system call is not available to non-root users on Unix. See limitations of chroot for more details.
The setuid and setgid bits are normally set with the command chmod by setting the high-order octal digit to 4 (for setuid) or 2 (for setgid). `chmod 6711` will set the setuid and setgid bits (6), make the file read/write/executable for the owner (7), and executable by the group (first 1) and others (second 1). All chmod flags are octal.
Most implementations of the chmod command also support finer-grained, 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.
[bobie]$ cat printid.c
#include <sys/types.h> #include <unistd.h> #include <stdio.h> int main(void) { printf( " UID GID \n" "Real %d Real %d \n" "Effective %d Effective %d \n", getuid (), getgid (), geteuid(), getegid() ); return 0; /* always good to return something */ }
[bobie]$ cc printid.c -o printid [bobie]$ ./printid UID GID Real 1008 Real 1008 Effective 1008 Effective 1008 [bobie]$ sudo chown root printid # to change the owner you need to sudo Password: [bobie]$ sudo chmod ug+s printid # SetUID and SetGID flags [bobie]$ sudo chmod o-rx printid # Don't let Others read or execute it [bobie]$ ls -l -rwsr-s--- 1 root staff 6944 2011-10-06 10:22 printid [bobie]$ ./printid UID GID Real 1008 Real 1008 Effective 0 Effective 20
setuid and setgid on directoriesThe 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 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). Newly created subdirectories inherit the setgid bit. Thus, this enables a shared workspace for a group without the inconvenience of requiring group members to explicitly change their current group before creating new files or directories. Note that setting the setgid permission on a directory only affects the group ID 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:
[root@foo]# find /path/to/directory -type d -exec chmod g+s {} \;
The setuid permission set on a directory is ignored on UNIX and Linux systems.[4] FreeBSD can be configured to interpret it analogously to setgid, namely, to force all files and sub-directories to be owned by the top directory owner.[5]
In FreeBSD, directories behave as if their setgid bit was always set, regardless of its actual value. As is stated in open(2), "When a new file is created it is given the group of the directory which contains it."
Programs that use this bit must be carefully designed to be immune to buffer overrun attacks. Successful buffer overrun attacks on vulnerable applications allow the attacker to execute arbitrary code under the rights of the process being exploited. In the event a vulnerable process uses the setuid bit to run as root, the code will be executed with root privileges, in effect giving the attacker root access to the system on which the vulnerable process is running.
The setuid bit was invented by Dennis Ritchie. His employer, AT&T, applied for a patent in 1972; the patent was granted in 1979 as patent number US 4135240 "Protection of data file contents". The patent was later placed in the public domain.[6]
chmodsudo