Não, o sticky bit não era como os sinalizadores set-UID ou set-GID. Não afetou nenhuma alteração nas credenciais do processo.
O que o pegajoso fez foi tornar o texto do programa "pegajoso". Não foi um equívoco, originalmente.
plano de fundo: seções da imagem do programa e texto compartilhado
Em essência, sem aprofundar muito os detalhes dos formatos de arquivo executáveis (que podem e possuem livros preenchidos): As partes dos arquivos de imagem do programa que são carregados diretamente na memória para executar programas compreendem código de máquina, constantes , os valores de inicialização de variáveis (não inicializadas de zero) e (de uma forma ou de outra) espaços em branco para variáveis inicializadas e não inicializadas.
Estes são agrupados em coleções conhecidas como "seções" e têm nomes convencionais. O código da máquina e (às vezes) as constantes formam o que é geralmente conhecido como a seção "texto" de uma imagem do programa. As variáveis não inicializadas como zero são, similarmente, a seção "data"; e as variáveis inicializadas e não inicializadas com zero são "bss" (um nome que tem toda uma história folclórica por trás).
Quando um processo tem um arquivo de imagem executável do programa carregado, as várias partes - texto, dados e bss - são inicializadas a partir do conteúdo do arquivo de imagem.
O que é especial na seção "texto" é que o código da máquina (e as constantes) quase sempre não é gravado. Ele tem o potencial de ser compartilhado nas imagens de memória virtual de todo o processo de execução que tinha esse arquivo de imagem executável carregado nelas. O cenário exato no qual o texto do programa pode ser compartilhado está fora do escopo dessa resposta e envolve itens como idempotência de correção do carregador e identidade do layout do espaço de endereço. As pessoas podem e escrever livros sobre esse assunto também. ☺
O texto compartilhado é uma otimização empregada pelo kernel. Ele elimina a necessidade de cada instância de uma única imagem de programa em execução ter sua própria imagem de memória individual, consumindo uma memória física preciosa com várias cópias do mesmo código de máquina (e constantes).
texto adesivo
Mas pode-se fazer melhor ainda que o texto compartilhado. Obviamente, se houver sempre pelo menos um processo em execução que esteja usando uma imagem de programa de texto compartilhado, o kernel simplesmente anexará o espaço de memória virtual dos novos processos ao segmento de texto compartilhado existente quando uma nova instância do programa for executada. Quase sempre há uma instância de (digamos) /bin/login ou /bin/sh executando algum lugar em um sistema de tamanho médio, para que novas instâncias do programa de login ou do shell padrão possam ser anexadas às cópias carregadas de seus segmentos de texto que o kernel já carregou na memória.
O texto fixo estende essa ideia para programar imagens que nenhum processo está executando atualmente . Se um arquivo de imagem executável for marcado como texto adesivo, o kernel manterá seu segmento de texto após a saída do último processo para usá-lo; na esperança de que uma outra instância do programa seja executada em breve e possa ser anexada ao segmento.
No início do Unices, os segmentos de texto fixo carregados seriam trocados para armazenamento de troca quando nenhum processo era anexado a eles. (Unices posteriores pararam de usar swap para isso.) Você também pode ter ouvido isso pelo nome texto salvo .
É claro que definir o bit de texto em uma imagem de programa é algo que deve ser feito com cuidado. Os programas que se beneficiam dependem do que a máquina geralmente é usada. E os segmentos de texto atualmente desanexados usam recursos do kernel, o que significa que há um limite prático para quantos podem ser usados em qualquer sistema. Portanto, geralmente é uma operação que requer privilégios de superusuário.
desuetude
Há toda uma carga de suposições subjacentes à operação de texto fixo, que simplesmente não são mais verdadeiras. A leitura de um segmento pré-fabricado a partir do armazenamento de troca não é necessariamente mais rápida que a simples paginação por demanda do arquivo de imagem executável real. Os formatos do sistema de arquivos tornaram-se melhores para padrões de leitura aleatórios (em oposição a seqüenciais). O advento da paginação por demanda em si altera as coisas, assim como coisas como caches unificados, ajustes externos não idempotentes resultantes de diferenças na pesquisa de biblioteca compartilhada e randomização de layout de espaço de endereço.
Os dias de bits de texto para imagens de programas executáveis desapareceram. Um sinalizador de marcador de texto fixo e explícito para imagens de programas executáveis foi considerado obsoleto pelos autores do 4.3BSD em meados dos anos 80, por exemplo.
Leitura adicional
- Maurice J. Bach (1986). O Design do Sistema Operacional UNIX . Prentice-Hall. ISBN 9780132017992.