Sticky bit

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 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. 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; Linux performs caching of executable files in the same way as all files, so re-executing the program to flush the cache is not necessary.

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.

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 -):

# ls -l test
-rw-r--r--   1 root     anygroup          0 Nov 10 12:57 test
# chmod +t test; ls -l test
-rw-r--r-T   1 root     anygroup          0 Nov 10 12:57 test
gollark: Hmm. I don't know how to Minoteaur the Minoteaurs.
gollark: Oh, right, the actual video: this is an amateur potatOS security researcher revealing a bug they found.
gollark: So the general and robust fix for this would be to stop doing I/O this way for anything but performance-sensitive and fairly robust (terminal, FS) I/O and API stuff, but PotatOS has so much legacy code that that would actually be very hard.
gollark: As it turns out, you can take a perfectly safe function with out of sandbox access and make it very not safe by controlling what responses it gets from HTTP requests and whatever.
gollark: And *another* Lua quirk more particular to CC is a heavy emphasis on event-driven I/O via coroutines.

See also

References
  1. "Archived copy". Archived from the original on 2005-01-18. Retrieved 2009-01-19.CS1 maint: archived copy as title (link)
  2. "Synopsis - man pages section 2: System Calls". Docs.oracle.com. 2011-11-01. Retrieved 2014-04-10.
  3. Archived November 20, 2007, at the Wayback Machine
  4. "chmod(1) - Linux manual page". Man7.org. Retrieved 2014-04-10.
  5. "chmod - FreeBSD". Nixdoc.net. 1993-06-04. Retrieved 2014-04-10.
  6. "chmod - IRIX/standard/". Nixdoc.net. Retrieved 2014-04-10.
  7. "Mac Developer Library". Developer.apple.com. Retrieved 2014-04-10.
  8. "sticky - NetBSD Manual Pages". Netbsd.gw.com. 2011-05-10. Retrieved 2014-04-10.
  9. "Manual Pages: sticky". Openbsd.org. 2014-02-14. Retrieved 2018-02-04.
  10. "chmod(2)". Uw714doc.sco.com. 2004-04-25. Retrieved 2014-04-10.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.