Por que um diretório teria o sticky bit definido sem o bit executável?

7

No Ubuntu 14.04, listando o conteúdo do diretório /var/spool/cron com ls -l fornece as seguintes permissões nos diretórios dentro (colunas irrelevantes cortadas):

drwxrwx--T daemon daemon atjobs
drwxrwx--T daemon daemon atspool
drwx-wx--T root crontab crontabs

Qual é o propósito de configurar um bit em um diretório sem que o bit executável seja exibido?

    
por Q23 28.04.2017 / 18:08

2 respostas

9

Na página de manual de sticky :

STICKY DIRECTORIES

A directory whose 'sticky bit' is set becomes an append-only directory, or, more accurately, 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 others' files.

Any user may create a sticky directory. See chmod(1) for details about modifying file modes.

O resultado disso é que somente o proprietário de um arquivo em um diretório fixo pode remover o arquivo. No caso das tabelas cron , isso significa que I não pode ir lá e remover sua tabela cron e substituí-la por uma de minha escolhendo, mesmo que eu possa ter acesso de gravação para o diretório. É por esse motivo que /tmp também é pegajoso.

    
por 28.04.2017 / 18:17
6

What purpose does setting a sticky bit on a directory without the executable bit serve?

drwx-wx--T 2 root crontab 4096 Apr 24 15:00 /var/spool/cron/crontabs/

O que você está vendo é semelhante no Debian. O diretório faz ter o bit executável definido, para o proprietário e o grupo. Apenas para o dono, o pegajoso não faz muito sentido, já que é, por definição, apenas um usuário (e o dono consegue se sobrepor de qualquer maneira). Mas, para o grupo, importa exatamente o mesmo que para diretórios graváveis do mundo, como /tmp , ou seja, usuários comuns não podem remover arquivos pertencentes a outros usuários.

Mas por que alguém seria um membro do grupo crontab ?

Poder modificar seus crontabs, é claro! crontab do Debian funciona com privilégio setgid, permitindo assim que qualquer usuário regular acesse esse diretório, com seu próprio UID e com o GID de crontab . Isso é um pouco mais seguro do que deixá-los executar o privilégio crontab with set uid , pois mantém os usuários separados uns dos outros.

-rwxr-sr-x 1 root crontab 36008 Jun 11  2015 /usr/bin/crontab

Agora, normalmente, os arquivos no diretório são de propriedade e nomeados por seus respectivos proprietários, e se crontab permitir apenas remover o próprio crontab do usuário, não haverá um problema. Tendo as permissões de arquivo configuradas para proteger contra bugs no programa, e tornam o UID real do usuário de acesso relevante, não apenas o nome .

    
por 28.04.2017 / 18:28