¿Qué hizo originalmente la parte adhesiva cuando se aplicó a los archivos?

En varios lugares se puede ver al "bit pegajoso" acusado de ser un nombre inapropiado, ya que su funcionalidad hoy en día es afectar los permisos de escritura en los directorios y actuar como un indicador de eliminación restringido .

En una respuesta de AskUbuntu, el respondedor escribió que "un poco pegajoso generalmente se aplica a los directorios" . Observé que, de hecho, los sistemas modernos parecen en la práctica nunca aplicarlo a los archivos, pero que hace mucho tiempo el caso habitual era que se aplicara a archivos (imagen de programa ejecutable) en lugar de directorios. (Cuando se trata de la escasez del uso moderno de los archivos, hay una pregunta relacionada en ¿No se utiliza el bit adhesivo en los sistemas de archivos actuales ?)

Esto provocó la pregunta:

¿Qué hizo un bit adhesivo aplicado a un ejecutable? ¿Era como setuid entonces?

Tenga en cuenta el tiempo pasado. Esto no es ¿Cómo funciona la parte adhesiva? ahora. Es como solía funcionar entonces.

No, el bit fijo no era como los indicadores set-UID o set-GID. No efectuó ningún cambio para procesar las credenciales.

Lo que hizo la parte pegajosa fue hacer que el texto del programa fuera "pegajoso". No fue un nombre inapropiado, originalmente.

fondo: secciones de imagen del programa y texto compartido

En esencia, sin profundizar en los detalles de los formatos de archivo ejecutables (que pueden y han llenado libros): las partes de los archivos de imagen del programa que se cargan directamente en la memoria para ejecutar programas comprenden código de máquina, constantes, el inicio valores de variables (no inicializadas en cero) y (de una forma u otra) espacios en blanco para variables inicializadas en cero y no inicializadas.

Estos se agrupan en colecciones conocidas como "secciones" y tienen nombres convencionales. El código de máquina y (a veces) las constantes forman lo que a menudo se conoce como la sección "texto" de una imagen de programa. Las variables no inicializadas en cero son, de manera similar, la sección "datos"; y las variables con inicialización cero y sin inicializar son "bss" (un nombre que en sí mismo tiene toda una historia folklórica detrás).

Cuando un proceso tiene un archivo de imagen ejecutable del programa cargado en él, las diversas partes (texto, datos y bss) se inicializan a partir del contenido del archivo de imagen.

Lo que es especial acerca de la sección "texto" es que el código de la máquina (y las constantes) casi siempre no se escribe. Tiene el potencial de ser compartido entre las imágenes de memoria virtual de todos los procesos en ejecución que tenían ese archivo de imagen ejecutable cargado en ellos. El escenario exacto en el que se puede compartir el texto del programa está fuera del alcance de esta respuesta e involucra cosas como la idempotencia de reparación del cargador y la identidad del diseño del espacio de direcciones. La gente también puede y ha escrito libros sobre este tema. ☺

El texto compartido es una optimización empleada por el núcleo. Elimina la necesidad de que cada instancia de una sola imagen de programa en ejecución tenga su propia imagen de memoria individual, consumiendo preciosa memoria física con múltiples copias del mismo código de máquina (y constantes).

texto adhesivo

Pero uno puede hacerlo mejor aún que el texto compartido. Obviamente, si siempre hay al menos un proceso en ejecución que usa una imagen de programa de texto compartido en particular, el núcleo simplemente conecta el espacio de memoria virtual de los nuevos procesos al segmento de texto compartido existente cuando se ejecuta una nueva instancia del programa. Casi siempre hay una instancia de (digamos) /bin/logino se /bin/shejecuta en algún lugar en un sistema de tamaño medio, por lo que las nuevas instancias del programa de inicio de sesión o el shell predeterminado pueden simplemente adjuntarse a las copias cargadas de sus segmentos de texto que el núcleo ya ha cargado en la memoria.

El texto adhesivo amplía esta idea para programar imágenes que actualmente no se está ejecutando ningún proceso . Si un archivo de imagen ejecutable se marca como texto adhesivo, el núcleo mantiene su segmento de texto después del último proceso para usarlo; con la esperanza de que otra instancia del programa se ejecute pronto y pueda volver a conectarse al segmento.

En los primeros Unices, los segmentos de texto fijo cargados se intercambiaban para intercambiar almacenamiento cuando no se les adjuntaba ningún proceso. (Más tarde, Unices dejó de usar el intercambio para esto). También es posible que haya oído hablar de esto por el nombre del texto guardado .

Por supuesto, establecer el bit de texto adhesivo en una imagen de programa es algo que debe hacerse con cuidado. Los programas que se benefician de él dependen de para qué se usa generalmente la máquina. Y los segmentos de texto actualmente no conectados ocupan los recursos del kernel, lo que significa que hay un límite práctico para la cantidad que se puede tener en cualquier sistema. Por lo tanto, generalmente es una operación que requiere privilegios de superusuario.

desuso

Hay una gran cantidad de suposiciones que subyacen a la operación del texto adhesivo, que simplemente ya no son ciertas. Leer un segmento prefabricado desde el almacenamiento de intercambio no es necesariamente más rápido que la simple paginación de demanda desde el archivo de imagen ejecutable real. Los formatos del sistema de archivos mejoraron para los patrones de lectura aleatorios (en lugar de secuenciales). El advenimiento de la paginación de la demanda en sí misma cambia las cosas, al igual que cosas como las memorias caché unificadas, las reparaciones externas no idempotentes que resultan de las diferencias en la búsqueda de bibliotecas compartidas y la aleatorización del diseño del espacio de direcciones.

Los días de los bits de texto adhesivo para las imágenes de programas ejecutables han quedado atrás. Por ejemplo, los escritores de 4.3BSD consideraron que un indicador de marcador de texto adhesivo explícito para imágenes de programas ejecutables era obsoleto a mediados de la década de 1980.

Otras lecturas

• Maurice J. Bach (1986). El diseño del sistema operativo UNIX . Prentice Hall. ISBN 9780132017992.