The Unix and Linux access rights flags setuid and setgid (short for set user identity and set group identity)[1] 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.
The flags setuid and setgid 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.
[2] Some of the tasks that require additional privileges may not immediately be obvious, though, such as the ping command, which must send and listen for control packets on a network interface.
The setuid and setgid flags have an effect only on binary executable files and not on scripts (e.g., Bash, Perl, Python).
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 account does not have the required privilege for sending packets.
Due to potential security issues,[4] many operating systems ignore the setuid attribute when applied to executable shell scripts.
[citation needed] The presence of setuid executables explains why the chroot system call is not available to non-root users on Unix.
[6] This is generally not needed on most systems derived from BSD, since by default directories are treated as if their setgid bit is always set, regardless of the actual value.
Without sticky bit, 'wozniak' could have deleted the file, because the directory named 'videogames' allows read and write by 'engineers'.
[8] For example, GNU libc was at one point vulnerable to an exploit using setuid and an environment variable that allowed executing code from untrusted shared libraries.