Como funciona a parte pegajosa?

Esta é provavelmente uma das coisas mais enfadonhas que as pessoas bagunçam o tempo todo. O bit SUID / GUID e o sticky-bit são duas coisas completamente diferentes.

Se você fizer um man chmod, poderá ler sobre o SUID e os sticky-bits. A página do manual também está disponível aqui .

background

excerto

As letras rwxXst selecione bits de modo de arquivo para o usuários afetados: ler (r), escrever (w), executar (ou pesquisar por diretórios) (x), executar / pesquisar apenas se o arquivo for um diretório ou já tiver permissão de execução para algum usuário (X), definir ID de usuário ou grupo na (s) execução (ões) , sinalizador de exclusão restrita ou bit pegajoso ( t) .

SUID / GUID

O que é a página de manual acima tentando dizer é que a posição que o bit x assume no rwxrwxrwx para o octal do usuário (1º grupo de rwx) e o grupo octal (2º grupo de rwx) pode assumir um estado adicional onde x se torna um s. Quando isso ocorre, este arquivo quando executado (se for um programa e não apenas um script de shell) será executado com as permissões do proprietário ou do grupo do arquivo.

Portanto, se o arquivo for de propriedade do root e o bit SUID estiver ativado, o programa será executado como root. Mesmo se você executá-lo como um usuário comum. O mesmo se aplica ao bit GUID.

trecho

SETUID E SETGID BITS

chmod limpa o bit set-group-ID de um arquivo normal se o ID de grupo do arquivo não corresponde ao ID de grupo efetivo do usuário ou a um dos IDs de grupo suplementares do usuário, a menos que o usuário tenha os privilégios apropriados. Restrições adicionais podem fazer com que os bits set-user-ID e set-group-ID de MODE ou RFILE sejam ignorados. Esse comportamento depende da política e da funcionalidade da chamada de sistema chmod subjacente. Em caso de dúvida, verifique o comportamento do sistema subjacente.

chmod preserva os bits set-user-ID e set-group-ID de um diretório, a menos que você especifique explicitamente o contrário. Você pode definir ou limpar os bits com o símbolo modos como u + s e gs, e você pode definir (mas não limpar) os bits com um modo numérico.

Exemplos de SUID / GUID

nenhum suid / guid – apenas os bits rwxr-xr-x são definidos .

$ ls -lt b.pl -rwxr-xr-x 1 root root 179 Jan 9 01:01 b.pl 

suid & bit executável do usuário ativado (minúsculas) – os bits rwsr-xrx são definidos.

$ chmod u+s b.pl $ ls -lt b.pl -rwsr-xr-x 1 root root 179 Jan 9 01:01 b.pl 

suid ativado & bit executável desativado (S maiúsculo) – os bits rwSr-xr-x estão definidos.

$ chmod u-x b.pl $ ls -lt b.pl -rwSr-xr-x 1 root root 179 Jan 9 01:01 b.pl 

guid & bit executável do grupo ativado (minúsculas) – os bits rwxr-sr-x são definidos.

$ chmod g+s b.pl $ ls -lt b.pl -rwxr-sr-x 1 root root 179 Jan 9 01:01 b.pl 

guid ativado & bit executável desativado (S maiúsculo) – os bits rwxr-Sr-x estão definidos.

$ chmod g-x b.pl $ ls -lt b.pl -rwxr-Sr-x 1 root root 179 Jan 9 01:01 b.pl 

bit sticky

O bit sticky no outro lado é denotado como t, como com o diretório /tmp:

$ ls -l /|grep tmp drwxrwxrwt. 168 root root 28672 Jun 14 08:36 tmp 

Este bit sempre deveria ter sido chamado de “bit de exclusão restrita”, pois é o que realmente significa. Quando este bit de modo está habilitado, ele cria um diretório de modo que os usuários só possam excluir arquivos & diretórios dentro dele dos quais são proprietários.

excerto

SINALIZADOR DE DELEÇÃO RESTRITO OU BIT PEGAJOSO

O sinalizador de exclusão restrita ou bit pegajoso é um único bit, cujo a interpretação depende do tipo de arquivo. Para diretórios,
evita que usuários sem privilégios removam ou renomeiem um arquivo no diretório, a menos que sejam proprietários do arquivo ou do diretório; isso é chamado de sinalizador de exclusão restrita para o diretório e é comumente encontrado em diretórios graváveis por todo o mundo, como / tmp.Para arquivos normais em alguns sistemas mais antigos, o bit salva a imagem de texto do programa no dispositivo de troca para que carregue mais rapidamente quando executado; isso é chamado de sticky bit.

Comentários

• Na verdade, o sticky-bit poderia ser aplicado anteriormente a executáveis, o que fazia com que eles permanecessem na troca após serem carregados pela primeira vez. Isso poderia salvar muito uso desnecessário de disco / rede (NFS) e CPU para programas que eram muito usados. No entanto, nem o Linux nem a maioria (todos?) dos sistemas Unix suportam mais isso (foi removido do kernel). It ' s " sticky ", porque o executável travou na troca. Além disso, foi usado para diretórios como você descreve.
• Na verdade, " muito usado ou muito grande " seria uma descrição melhor. Lembre-se de que minha faculdade tinha o navegador da web Netscape como " aderente " em seu computador HP-UX em 1995. Programas tão pequenos que eram usados com frequência (por exemplo, comandos do sistema executados com freqüência por cron) e programas grandes (por exemplo, Netscape) eram os principais candidatos a se tornarem " fixos ". Em ambos os casos, recarregá-los constantemente do disco / NFS seria um desperdício.
• Os programas sticky-bit deveriam permanecer residentes na RAM, não na troca (carregar uma imagem de um arquivo de troca isn ' t muito mais rápido do que carregá-lo de um disco do sistema de arquivos). Ele foi projetado para comandos essenciais no nível do sistema operacional, como ls. Obviamente, apenas o superusuário pode definir o sticky bit em um arquivo. Tornou-se menos importante depois que a memória virtual e as bibliotecas compartilhadas foram introduzidas, e especialmente quando os pagers se tornaram mais inteligentes e podem decidir dinamicamente quais páginas manter residentes.
• E como a propriedade sticky não fazia sentido para um diretório, o mesmo parte da máscara de permissões foi mais tarde interpretada para modificar a semântica tradicional de criação de arquivos para diretórios.
• @alexis: Originalmente, os programas de bits fixos eram mantidos no espaço de troca. Isso era muito mais rápido do que ler do sistema de arquivos porque as imagens do arquivo de troca de leitura eram setores contíguos e, portanto, podiam ser lidas principalmente de forma assíncrona. Com os primeiros sistemas de arquivos, não havia " extensões de execução " e os primeiros drivers de sistema de arquivos liam um setor por vez, mesmo que os setores passou a ser consecutivo. O resultado em um PDP-40 era que os programas pegajosos pareciam carregar instantaneamente, enquanto os programas não pegajosos demoravam um ou dois segundos. Acho que tivemos apenas ed fixo.