Sticky bit

Nei sistemi operativi Unix e Unix-like, ed in generale nei sistemi POSIX, lo sticky bit è un permesso speciale che può essere associato ad un file (tipicamente ai file eseguibili) o ad una directory.

Per i file, principalmente di tipo eseguibile, l'utente amministratore li può etichettare, in gergo taggare, in modo da farli mantenere nella memoria principale, anche quando il bisogno di essi termina, per ridurre al minimo gli scambi che si verificherebbero quando si presentasse un'altra necessità, e i file adesso dovrebbero essere ricaricati dalla memoria secondaria, relativamente lenta.^[1] Questa funzione è diventata obsoleta a causa dell'ottimizzazione della tecnica di scambio, detta swapping.

Per le directory, quando il loro sticky bit è impostato, il filesystem tratta i file contenuti in tali directory in maniera speciale: solo il proprietario dei file, della directory o l'utente amministratore possono rinominare o cancellare i file. Senza lo sticky bit settato, qualsiasi utente con permessi di scrittura ed esecuzione nella directory potrebbero rinominare o cancellare i file contenuti in essa, indipendentemente dal proprietario dei file. Tipicamente questo bit viene settato alla directory dei file temporanei /tmp per prevenire che account di utenti ordinari possano cancellare o spostare file di altri utenti.

La moderna funzione dello sticky bit è rivolta alle directory: protegge esse e il loro contenuto dalla possibilità che vengano modificate maliziosamente da utenti non-proprietari; esso è presente nella maggior parte dei moderni sistemi Unix-like.

I file presenti in una cartella comune condivisa come /tmp fanno comunque affidamento ai singoli proprietari; gli altri utenti potrebbero non essere in grado di cancellarli, sovrascriverli o rinominarli.

Storia

Lo sticky bit venne introdotto nella quinta edizione di UNIX, nel 1974, per essere usato solo su file eseguibili. Se impostato, esso forzava il sistema operativo a mantenere nello spazio di swap l'immagine del programma anche dopo che il processo relativo era terminato. Questo comportamento velocizzava le esecuzioni successive, in quanto lo spazio di swap era gestito come un file contiguo, e quindi più rapido da rileggere rispetto ai file eseguibili, che potevano essere memorizzati in maniera frammentata all'interno del file system.^[2] I programmi avviati frequentemente, come gli editor di testo, ne guadagnavano molto in velocità d'avvio. Tra i problemi causati dall'uso dello sticky bit vi era quello della sostituzione del file eseguibile originale: per poterlo fare bisognava innanzitutto rimuovere lo sticky bit dal file eseguibile, quindi eseguire il programma e poi uscirne al fine di pulire la cache, per poi sostituire il file eseguibile ed infine ripristinare lo sticky bit.

La velocità guadagnata in esecuzioni ripetute andò persa quando Unix venne portato sui sistemi hardware con il supporto per l'accesso diretto alla memoria (Direct Memory Access) da parte dei dispositivi di memoria di massa, ed anche su quelli che sostituivano il sistema di swapping con il paging. Nonostante ciò, lo sticky bit restò operativo in molte varianti della Versione 5 (in particolare sui sistemi Solaris ^[3] e su HP-UX). La release 4.4 Lite del BSD mantenne il supporto allo sticky bit sul proprio sistema, per poi eliminarlo nella versione OpenBSD (dalla release 3.7) e FreeBSD (dalla release 2.2.1); rimane in NetBSD. Nessuna versione di Linux ha mai supportato il comportamento tradizionale per i file eseguibili.

Uso

Al giorno d'oggi lo sticky bit viene comunemente usato per le directory destinate a contenere file temporanei di più utenti: se impostato su una directory esso indica che i file e subdirectory in essa contenuti possono essere cancellati o rinominati solo dal proprietario, o dal proprietario della directory che lo contiene o dall'utente root, anche se si dispongono di tutti gli altri permessi di scrittura necessari. Questo permesso viene spesso impostato sulle directory /tmp e /var/tmp per evitare che utenti ordinari cancellino o spostino i file temporanei appartenenti agli altri utenti, pur consentendo a chiunque di creare nuovi file e directory. Questo comportamento venne introdotto nel 4.3BSD (1986) ed è tuttora presente in molti sistemi Unix.

Su Solaris, a partire da SunOS 2.5, lo sticky bit può essere impostato dall'amministratore (root) su file non eseguibili per indicare al kernel di non mantenere in cache i dati di tali file. L'uso è tipico con i file di swap, per evitare che le operazioni di accesso a tali file finiscano con l'occupare la cache a scapito di altri dati più importanti. Questo comportamento viene occasionalmente sfruttato anche per effettuare dei test che misurano le prestazioni del sistema (benchmark).

Estratti dalle pagine man relative agli effetti dello sticky bit sulle directory e sui file^[4]

Sistema Operativo	Directory	File
AIX 5.2[5]	indicates that only file owners can link or unlink files in the specified directory.	sets the save-text attribute.
Solaris 11[6]	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[7]	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[8]	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[9]	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[10]	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 exec'ed 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)[11]	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[12]	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[13]	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[14]	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.

Esempi

Lo sticky bit può essere impostato tramite il comando chmod, specificandolo tramite la sua rappresentazione ottale 1000 o tramite la rappresentazione simbolica t (s è già usato per il permesso setuid).

Ad esempio, per impostarlo sulla directory /usr/local/tmp, directory condivise per file temporanei, si può usare il comando

 # chmod +t /usr/local/tmp

Per assicurarsi che tale directory abbia anche gli altri permessi standard si può usare

 # chmod 1777 /usr/local/tmp

Invece per rimuoverlo si può utilizzare il comando

 # chmod -t /usr/local/tmp

oppure

 # chmod 0777 /usr/local/tmp

il quale inoltre setta i permessi standard alla directory tmp.

Nella notazione simbolica dei permessi, la presenza dello sticky bit è segnalata dalla lettera t all'ultimo posto (quello altrimenti usato per indicare il permesso di esecuzione x per la classe altri). Ad esempio, su Solaris 8, la directory /tmp, che normalmente ha lo sticky bit attivato, viene mostrata così:

$ ls -ld /tmp
drwxrwxrwt   4 root     sys          485 Nov 10 06:01 /tmp

In caso di file o directory privi del permesso di esecuzione per la classe altri, viene invece usata la lettera T maiuscola (sostituendo quello che altrimenti sarebbe -), ad esempio:

# 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