Editing Setuid (section)

==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>