No, la parte adesiva non era come i flag set-UID o set-GID. Non ha apportato modifiche al processo di credenziali.
Quello che ha fatto la parte adesiva è stata rendere il testo del programma "appiccicoso". In origine non era un termine improprio.
sfondo: sezioni di immagini del programma e testo condiviso
In sostanza, senza approfondire troppo i dettagli dei formati di file eseguibili (che possono e hanno libri pieni): le parti dei file di immagine del programma che vengono caricate direttamente in memoria per eseguire i programmi comprendono codice macchina, costanti, avvio valori di variabili (non inizializzate con zero) e (in una forma o nell'altra) spazi vuoti per variabili con inizializzazione zero e non inizializzate.
Questi sono raggruppati in raccolte note come "sezioni" e hanno nomi convenzionali. Il codice macchina e (a volte) le costanti formano quella che è spesso conosciuta come la sezione "testo" di un'immagine di programma. Le variabili non zero inizializzate sono, analogamente, la sezione "dati"; e le variabili zero inizializzate e non inizializzate sono "bss" (un nome che ha una storia folcloristica alle spalle).
Quando in un processo è caricato un file di immagine eseguibile del programma, le varie parti (testo, dati e bss) vengono inizializzate dal contenuto del file di immagine.
La particolarità della sezione "testo" è che il codice macchina (e le costanti) non viene quasi sempre scritto. Ha il potenziale per essere condiviso tra le immagini della memoria virtuale di tutto il processo di esecuzione in cui è stato caricato quel file di immagine eseguibile. Lo scenario esatto in cui è possibile condividere il testo del programma non rientra nell'ambito di questa risposta e coinvolge elementi come l'idempotenza della correzione del caricatore e l'identità del layout dello spazio degli indirizzi. Le persone possono e hanno anche scritto libri su questo argomento. ☺
Il testo condiviso è un'ottimizzazione utilizzata dal kernel. Elimina la necessità per ogni istanza di una singola immagine del programma in esecuzione di avere la propria immagine di memoria individuale, consumando preziosa memoria fisica con più copie dello stesso identico codice macchina (e costanti).
testo appiccicoso
Ma si può fare ancora meglio del testo condiviso. Ovviamente, se c'è sempre almeno un processo in esecuzione che utilizza una particolare immagine di programma di testo condiviso, il kernel può semplicemente collegare lo spazio di memoria virtuale dei nuovi processi al segmento di testo condiviso esistente quando viene eseguita una nuova istanza del programma. C'è quasi sempre un'istanza di (diciamo) /bin/logino in /bin/shesecuzione da qualche parte su un sistema di medie dimensioni, quindi nuove istanze del programma di accesso o della shell predefinita possono semplicemente collegarsi alle copie caricate dei loro segmenti di testo che il kernel ha già caricato in memoria.
Il testo appiccicoso estende questa idea per programmare immagini che nessun processo è attualmente in esecuzione . Se un file di immagine eseguibile è contrassegnato come testo appiccicoso, il kernel mantiene il suo segmento di testo in giro dopo l'ultimo processo per usarlo; nella speranza che un'altra istanza del programma venga eseguita presto e possa semplicemente ricollegarsi al segmento.
Nei primi Unices, i segmenti di testo appiccicosi caricati venivano scambiati per scambiare l'archiviazione quando non era collegato alcun processo. (In seguito Unices smise di usare lo swap per questo.) Potresti anche aver sentito parlare di questo con il nome del testo salvato .
Naturalmente, impostare il bit di testo appiccicoso sull'immagine di un programma è qualcosa che deve essere fatto con cura. I programmi che ne traggono beneficio dipendono dall'uso generale della macchina. E i segmenti di testo attualmente non collegati occupano risorse del kernel, il che significa che esiste un limite pratico a quanti si possono avere in qualsiasi sistema. Quindi è generalmente un'operazione che richiede i privilegi di superutente.
disuso
C'è un sacco di ipotesi alla base dell'operazione del testo appiccicoso, che non sono più vere. La lettura di un segmento pre-creato dalla memoria di scambio non è necessariamente più veloce del semplice paging della domanda dal file di immagine eseguibile effettivo. I formati di filesystem sono diventati migliori per schemi di lettura casuali (piuttosto che sequenziali). L'avvento del paging della domanda stesso cambia le cose, così come cose come cache unificate, correzioni esterne non idempotenti risultanti da differenze nella ricerca di librerie condivise e randomizzazione del layout dello spazio degli indirizzi.
I giorni dei bit di testo appiccicosi per le immagini dei programmi eseguibili sono passati da tempo. Ad esempio, a metà degli anni '80, gli scrittori di 4.3BSD hanno considerato una bandiera marcatore di testo esplicito appiccicoso per le immagini di programmi eseguibili.
Ulteriori letture
- Maurice J. Bach (1986). Il design del sistema operativo UNIX . Prentice-Hall. ISBN 9780132017992.