View source for Setuid

{{short description|Unix access rights flag}}
{{Lowercase title}}
{{Redirect|SGID|the company which briefly used this stock ticker symbol|Silicon Graphics}}

In [[Unix-like]] systems, the access rights flags '''setuid''' and '''setgid''' (short for ''set user identity'' and ''set group identity'')<ref>{{cite book|first=William |last=von Hagen |title=Ubuntu Linux Bible|url=https://books.google.com/books?id=rsSlrQLB8-gC&q=set%20user%20ID%20upon%20execution&pg=SA3-PA59 |pages=3–59|isbn=9780470881804|date=2010-05-13|publisher=John Wiley & Sons }}</ref> 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 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 <code>setuid</code> and <code>setgid</code> 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.<ref name="oreilly">{{cite book|first=Æleen |last=Frisch |title=Essential system administration| url=https://books.google.com/books?id=uRW8V9QOL7YC&q=setuid&pg=PT375 |page=351|publisher= O'Reilly|isbn=9780596550493|date=2009-02-09}}</ref> Some of the tasks that require additional privileges may not immediately be obvious, though, such as the <code>[[ping (networking utility)|ping]]</code> command, which must send and listen for [[Internet Control Message Protocol|control packet]]s on a network interface.

==File modes==

The <code>setuid</code> and <code>setgid</code> bits are normally represented as the values 4 for <code>setuid</code> and 2 for <code>setgid</code> in the high-order octal digit of the file mode. For example, <code>6711</code> has both the <code>setuid</code> and <code>setgid</code> bits ({{nowrap|4 + 2 {{=}} 6}}) set, and also the file read/write/executable for the owner (7), and executable by the group (first 1) and others (second 1). Most implementations have a symbolic representation of these bits; in the previous example, this could be <code>u=rwx,go=x,ug+s</code>.

Typically, <code>chmod</code> does not have a recursive mode restricted to directories, so modifying an existing directory tree must be done manually, with a command such as {{code|find /path/to/directory -type d -exec chmod g+s '{}' '\'|sh}}.

==Effects==

The <code>setuid</code> and <code>setgid</code> 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 <code>setuid</code> and <code>setgid</code> flags have an effect only on binary executable files and not on scripts (e.g., Bash, Perl, Python).<ref>{{cite book |last1=Billimoria |first1=Kaiwan N. |title=Hands-On System Programming with Linux: Explore Linux system programming interfaces, theory, and practice |date=2018 |publisher=Packt Publishing Ltd |isbn=978-1-78899-674-7 |page=250 |url=https://books.google.com/books?id=aOh1DwAAQBAJ&pg=PA250}}</ref>

===When set on an executable file===

When the <code>setuid</code> or <code>setgid</code> 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 [[superuser|root]]) and/or the file's group, depending upon the flags set.<ref name="oreilly" /> 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 (networking utility)|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 account does not have the required privilege for sending packets.

==== Security impact====
For security purposes, the invoking user is usually prohibited by the system from altering the new process in any way, such as by using <code>[[ptrace]]</code>, <code>LD_LIBRARY_PATH</code> or sending signals to it, to exploit the raised privilege, although signals from the terminal will still be accepted.

While the <code>setuid</code> feature is very useful in many cases, its improper use can pose a security risk<ref name="oreilly" /> if the <code>setuid</code> attribute is assigned to [[executable]] programs that are not carefully designed. Due to potential security issues,<ref>{{cite web|url=http://www.faqs.org/faqs/unix-faq/faq/part4/section-7.html|title=Unix - Frequently Asked Questions}}</ref> many operating systems ignore the <code>setuid</code> attribute when applied to executable ''[[shell script]]s''.{{cn |date=March 2024}}

The presence of <code>setuid</code> executables explains why the <code>[[chroot]]</code> system call is not available to non-[[superuser|root]] users on Unix. See [[chroot#Limitations|limitations of <code>chroot</code>]] for more details.

===When set on a directory===
Setting the <code>setgid</code> permission on a directory causes files and subdirectories created within to inherit its group ownership, rather than the primary group of the file-creating process. Created subdirectories also inherit the <code>setgid</code> bit. The policy is only applied during creation and, thus, only prospectively. Directories and files existing when the <code>setgid</code> bit is applied are unaffected, as are directories and files moved into the directory on which the bit is set.

Thus is granted a capacity to work with files amongst a group of users without explicitly setting permissions, but limited by the security model expectation that existing files permissions do not implicitly change.

The <code>setuid</code> permission set on a directory is ignored on most [[UNIX]] and [[Linux]] systems.<ref>{{cite web |title=27.5 Directories and the Set-User-ID and Set-Group-ID Bits |url=https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html#Directories-and-the-Set_002dUser_002dID-and-Set_002dGroup_002dID-Bits |website=GNU Coreutils 9.1 |publisher=Free Software Foundation |access-date=13 December 2022}}</ref>{{Citation needed|date=November 2017}} However [[FreeBSD]] can be configured to interpret <code>setuid</code> in a manner similar to <code>setgid</code>, 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.<ref>{{cite web |url=http://www.freebsd.org/cgi/man.cgi?query=chmod&apropos=0&sektion=0&manpath=FreeBSD+6.1-RELEASE&format=html |title=chmod -- change file modes|website=freebsd.org}}</ref> This is generally not needed on most systems derived from [[BSD]], since by default directories are treated as if their <code>setgid</code> bit is always set, regardless of the actual value. As is stated in <code>open(2)</code>, "When a new file is created it is given the group of the directory which contains it."<ref>{{cite web |title=open, openat -- open or create a file for reading, writing or executing|url=https://www.freebsd.org/cgi/man.cgi?query=open&sektion=2 |website=freebsd.org}}</ref>

==Examples==
===Checking permissions===

Permissions of a file can be checked in octal form and/or alphabetic form with the command line tool <code>stat</code>

<syntaxhighlight lang="console">
[ torvalds ~ ] $ stat -c "%a %A" ~/test/
1770 drwxrwx--T
</syntaxhighlight>

===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 <code>/usr/bin/passwd</code> binary file. <code>/usr/bin/passwd</code> needs to modify <code>/etc/passwd</code> and <code>/etc/shadow</code> which store account information and password hashes for all users, and these can only be modified by the user 'root'.<syntaxhighlight lang="console">
[ thompson ~ ] $ stat -c "%a %U:%G %n" /usr/bin/passwd
4701 root:root /usr/bin/passwd

[ thompson ~ ] $ passwd
passwd: Changing password for thompson
</syntaxhighlight>

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'.
<syntaxhighlight lang="console">
[ 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
</syntaxhighlight>

===Sticky bit===
{{see also|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 <code>/tmp</code> folder.
<syntaxhighlight lang="console">
[ 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
</syntaxhighlight>

=== 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.<syntaxhighlight lang="console">
[ 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!
</syntaxhighlight>

== Security ==
Developers design and implement programs that use this bit on executables carefully in order to avoid security vulnerabilities including [[buffer overrun]]s 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 <code>setuid</code> bit to run as <code>root</code>, 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 <code>setuid</code> process is the [[Environment (computing)|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.<ref>{{cite web |title=Ghosts of Unix past, part 4: High-maintenance designs |url=https://lwn.net/Articles/416494/ |first=Neil |last=Brown |date=November 23, 2010 |website=LWN.net |accessdate=30 March 2014}}</ref> For example, [[GNU libc]] was at one point vulnerable to an [[security exploit|exploit]] using <code>setuid</code> and an environment variable that allowed executing code from untrusted [[shared libraries]].<ref>{{cite web |title=Two glibc vulnerabilities |url=https://lwn.net/Articles/412048/ |first=Jake |last=Edge |date=October 27, 2010 |website=LWN.net |accessdate=30 March 2014}}</ref>

==History==
The <code>setuid</code> bit was invented by [[Dennis Ritchie]]<ref name="reader">{{cite tech report |first1=M. Douglas |last1=McIlroy |authorlink1=Doug McIlroy |year=1987 |url=http://www.cs.dartmouth.edu/~doug/reader.pdf |title=A Research Unix reader: annotated excerpts from the Programmer's Manual, 1971–1986 |series=CSTR |number=139 |institution=Bell Labs}}</ref> and included in <code>[[su (Unix)|su]]</code>.{{r|reader}} His employer, then [[Bell Telephone Laboratories]], applied for a patent in 1972; the patent was granted in 1979 as patent number {{patent|US|4135240|"Protection of data file contents"}}. The patent was later placed in the [[public domain]].<ref>{{cite web |url=http://www.textfiles.com/law/softpat.txt |title=Summary of key software patents }}</ref>

== See also ==
{{Columns-list|colwidth=22em|
* [[User identifier]]
* [[Group identifier]]
* [[Process identifier]]
* <code>[[chmod]]</code>
* <code>[[sudo]]</code>
* [[Confused deputy problem]]
* [[PolicyKit]]
* [[Unix security]]
* [[Privilege revocation (computing)]]
* [[Privilege separation]]
}}

== References ==
{{Reflist|30em}}

==External links==
* Chen, Hao; [[David A. Wagner|Wagner, David]]; and Dean, Drew; [http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf <cite>Setuid Demystified</cite>] (pdf)
* Tsafrir, Dan; [[Dilma Da Silva|Da Silva, Dilma]]; and Wagner, David; [http://www.eecs.berkeley.edu/~daw/papers/setuid-login08b.pdf <cite>The Murky Issue of Changing Process Identity: Revising Setuid Demystified</cite>] (pdf)
* Pollock, Wayne; [http://wpollock.com/AUnix1/FilePermissions.htm Unix File and Directory <cite>Permissions and Modes</cite>]

[[Category:Computer security procedures]]
[[Category:Unix file system technology]]
[[Category:Patents placed into the public domain]]