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 "sticked" 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. 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.
The most common use of the sticky bit today is on directories. When the sticky bit is set, only the item's owner, the directory's owner, or the superuser can rename or delete files. Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of 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 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.
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.
|Operating System||Excerpt from Man pages regarding sticky bit on files||Links|
|AIX 5.2||For directories, indicates that only file owners can link or unlink files in the specified directory. For files, sets the save-text attribute.||AIX chmod (2)|
|Solaris 11||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 the S_ISVTX bit is set on any other file, the results are unspecified. 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||Solaris chmod(2)|
|HP-UX||[...] 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.||hp-ux chmod(2)|
|Linux||[...] the Linux kernel ignores the sticky bit on files. [...] When the sticky bit is set on a directory, files in that directory may only be unlinked or renamed by root or the directory owner or the file owner.||Linux chmod(1)|
|FreeBSD||The FreeBSD VM system totally ignores the sticky bit (ISVTX) for executables. If mode ISVTX (the `sticky bit') is set on a directory, an unprivileged user may not delete or rename files of other users in that directory.||FreeBSD chmod(2)|
|IRIX||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.||IRIX chmod(2)|
|Mac OS X (Leopard)||The ISVTX (the sticky bit) has no effect on executable files. All optimization on whether text images remain resident in memory is handled by the kernel's virtual memory system. A directory whose 'sticky bit' is set becomes an append-only directory, or, more accurately, 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. Any user may create a sticky directory.||Mac OS X sticky(8)|
|NetBSD||The sticky bit can be set on files, but without any effect. It is reserved for future use.||NetBSD sticky(8)|
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.
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.
|SCO UnixWare||If a 0410 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 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.||Unixware chmod(2)|
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 (using numeric mode will also change directory tmp to standard permissions).
In Unix symbolic file system permission notation, the sticky bit is represented by the letter t in the final character-place. 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:
# ls -l test -rw-r--r-- 1 root other 0 Nov 10 12:57 test # chmod +t test; ls -l test -rw-r--r-T 1 root other 0 Nov 10 12:57 test