{{About|the filesystem concept|the technique in floating-point arithmetic|Floating point#Addition and subtraction}}{{More footnotes|date=September 2014}}
In computing, the sticky bit is a user ownership access right flag that can be assigned to files and directories on Unix-like systems.
When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root user can rename or delete the file. Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of the file's owner. Typically this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files.
The modern function of the sticky bit was introduced in 4.3BSD{{discuss|origin of sticky bit}} in 1986, and is found in most modern Unix-like systems.
History
The sticky bit was introduced in the Fifth Edition of Unix (in 1974) for use with pure executable files. When set, it instructed the operating system to retain the text segment of the program in swap space after the process exited. This speeds up subsequent executions by allowing the kernel to make a single operation of moving the program from swap to real memory. Thus, frequently-used programs like editors would load noticeably faster. One notable problem with "stickied" programs was replacing the executable (for instance, during patching); to do so required removing the sticky bit from the executable, executing the program and exiting to flush the cache, replacing the binary executable, and then restoring the sticky bit.
Currently, this behavior is only operative in HP-UX and UnixWare. Solaris appears to have abandoned this in 2005.{{Citation needed|date=September 2008}} The 4.4-Lite release of BSD retained the old sticky bit behavior, but it has been subsequently dropped from OpenBSD (as of release 3.7) and FreeBSD (as of release 2.2.1). No version of Linux has ever supported this traditional behavior.
Usage
The most common use of the sticky bit is on directories residing within filesystems for Unix-like operating systems. When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root can rename or delete the file. Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of the file's owner. Typically, this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files. This feature was introduced in 4.3BSD in 1986, and today it is found in most modern Unix-like systems.
In addition, Solaris (as of Solaris 2.5) defines special behavior when the sticky bit is set on non-executable files: those files, when accessed, will not be cached by the kernel. This is usually set on swap files to prevent access on the file from flushing more important data from the system cache. It is also used occasionally for benchmarking tests.{{Citation needed|date=October 2010}}
The sticky bit is also set by the automounter to indicate that a file has not been mounted yet. This allows programs like ls to ignore unmounted remote files.
Excerpts from man pages about the sticky bit's effect on directories and files
Operating System
Directories
Files
AIX 5.2[1]
indicates that only file owners can link or unlink files in the specified directory.
sets the save-text attribute.
Solaris 11[2]
If a directory is writable and has S_ISVTX (the sticky bit) set, files within that directory can be removed or renamed only if one or more of the following is true (see unlink(2) and rename(2)): the user owns the file, the user owns the directory, the file is writable by the user, the user is a privileged user.
If a regular file is not executable and has S_ISVTX set, the file is assumed to be a swap file. In this case, the system's page cache will not be used to hold the file's data. If […] set on any other file, the results are unspecified.
HP-UX[3]
If […] set on a directory, an unprivileged user cannot delete or rename others' files in that directory.
[…] prevents the system from abandoning the swap-space image of the program-text portion of the file when its last user terminates. Then, when the next user of the file executes it, the text need not be read from the file system but can simply be swapped in, thus saving time.
Linux[4]
When […] set on a directory, files in that directory may only be unlinked or renamed by root or the directory owner or the file owner.
the Linux kernel ignores the sticky bit on files.
FreeBSD[5]
If […] set on a directory, an unprivileged user may not delete or rename files of other users in that directory.
The FreeBSD VM system totally ignores the sticky bit (S_ISVTX) for executables.
IRIX[6]
If […] set on a directory, then any files created in that directory will take on the group ID of the directory rather than the group ID of the calling process. mount(1M) may be used to enable this feature regardless of the mode of the directory.
If the sticky bit, S_ISVTX, is set on a file that is a dynamic loader for an ELF executable, then when the executable is execed the old process's read only address spaces will be made available to the dynamic loader in the new process. This can improve program start up time considerably. The setting of the sticky bit on any other file has no effect.
Mac OS X (Leopard)[7]
A directory whose 'sticky bit' is set becomes an append-only directory […] in which the deletion of files is restricted. A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each other's files. Any user may create a sticky directory.
The sticky bit has no effect on executable files. All optimisation on whether text images remain resident in memory is handled by the kernel's virtual memory system.
NetBSD[8]
A directory whose 'sticky bit' is set becomes a directory in which the deletion of files is restricted. A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each other's files.
NetBSD does not currently treat regular files that have the sticky bit set specially, but this behavior might change in the future.
OpenBSD[9]
A directory with the `sticky bit' set places restrictions on file deletion: a file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the superuser. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each other's files.
Any user may create a sticky directory. See chmod(1) for details about modifying file modes.
Historically, an executable shareable file which had the sticky bit set was not immediately discarded from swap space after execution. The kernel hoarded the text segment of the file for future reuse, thus avoiding having to reload the program. This is no longer true on modern systems; the current virtual memory system keeps track of recently used executables, making the sticky bit for files redundant. The sticky bit can still be set on files, but without any effect.
Only the superuser can set the sticky bit on a file, though the owner of the file may clear the sticky bit.
SCO UnixWare[10]
If a directory is writable and the sticky bit, S_ISVTX, is set on the directory, a process may remove or rename files within that directory only if one or more of the following is true:
the effective user ID of the process is the same as that of the owner ID of the file
the effective user ID of the process is the same as that of the owner ID of the directory
the process has write permission for the file
the process has the P_OWNER privilege
If a 0410 a.out executable file has the sticky bit (mode bit 01000) set, the operating system will not delete the program text from the swap area when the last user process terminates. If a 0413 a.out or ELF executable file has the sticky bit set, the operating system will not delete the program text from memory when the last user process terminates. In either case, if the sticky bit is set the text will already be available (either in a swap area or in memory) when the next user of the file executes it, thus making execution faster.
Examples
The sticky bit can be set using the chmod command and can be set using its octal mode 1000 or by its symbol t (s is already used by the setuid bit). For example, to add the bit on the directory /usr/local/tmp, one would type chmod +t /usr/local/tmp. Or, to make sure that directory has standard tmp permissions, one could also type chmod 1777 /usr/local/tmp.
To clear it, use chmod -t /usr/local/tmp or chmod 0777 /usr/local/tmp (the latter will also reset the tmp directory to standard permissions).
In Unix symbolic file system permission notation, the sticky bit is represented by the letter t in the final character-place, replacing what would otherwise be x. For instance, on Solaris 8, the /tmp directory, which by default has the sticky-bit set, shows up as:
$ ls -ld /tmp
drwxrwxrwt 4 root sys 485 Nov 10 06:01 /tmp
If the sticky-bit is set on a file or directory without the execution bit set for the others category (non-user-owner and non-group-owner), it is indicated with a capital T (replacing what would otherwise be -):
[https://web.archive.org/web/20120203044307/http://content.hccfl.edu/pollock/AUnix1/FilePermissions.htm Unix File and Directory Permissions], 2010, by Wayne Pollock, archived from the original on February 3, 2012
{{DEFAULTSORT:Sticky Bit}}
2 : Unix file system technology|File system permissions