Setuid

From Wikipedia, the free encyclopedia

The correct title of this article is setuid. The initial letter is shown capitalized due to technical restrictions.

setuid and setgid are Unix terms, which are short for "Set User ID" and "Set Group ID", respectively. setuid (also sometimes referred to as "suid") and setgid are access right flags that can be assigned to files and directories on a Unix based operating system. They are mostly used to allow users on a computer system to execute binary executables with temporarily elevated privileges in order to perform a specific task.

setuid and setgid are needed for tasks that require higher privileges than those which a common user has, such as changing his or her login password. Some of the tasks that require elevated privilege may not immediately be obvious, though -- such as the ping command, which must send and listen for control packets on a network interface.

1 setuid on executables
- 1.1 Demonstration
2 setuid on directories
3 See also
4 External links

[edit] 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 is the main reason why the chroot system call is not available to non-root users on Unix.

[edit] Demonstration

[bob@foo]$ cat /etc/passwd
alice:x:1007:1007::/home/alice:/bin/bash
bob:x:1008:1008::/home/bob:/bin/bash

[bob@foo]$ cat print_id.c

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>

int main(void)
{
    printf("Real UID\t= %d\n", getuid());
    printf("Effective UID\t= %d\n", geteuid());
    printf("Real GID\t= %d\n", getgid());
    printf("Effective GID\t= %d\n", getegid());

    return EXIT_SUCCESS;
}

[bob@foo]$ gcc -Wall print_id.c -o print_id
[bob@foo]$ chmod ug+s print_id
[bob@foo]$ su alice 
Password: 
[alice@foo]$ ./print_id 
Real UID        = 1007
Effective UID   = 1008
Real GID        = 1007
Effective GID   = 1008
[alice@foo]$

[edit] setuid on directories

setuid and setgid flags on a directory have an entirely different meaning.

Directories with the setgid permission will force all files and sub-directories created in them to be owned by the directory group and not the group of the user creating the file. The setgid flag is inherited by newly created subdirectories.

The setuid permission set on a directory is ignored on UNIX and Linux^{[citation needed]} systems, but FreeBSD interprets it similarly to setgid, namely, all files and sub-directories are forced to be owned by the directory owner.^[1]