Por que o setuid é ignorado nos diretórios?

Nos sistemas Linux, é possível com êxito chmod u+s $some_directory, mas, em vez de forçar a propriedade de novos subdiretórios e arquivos a ser o proprietário do diretório que contém (e também definir subdiretórios u+s) conforme o esperado, o sistema simplesmente ignora o bit setuid. Os subdiretórios e arquivos continuam a herdar os UIDs de seus processos de criação, e os subdiretórios não são configurados por padrão.

Por que o setuid é ignorado nos diretórios e como posso fazer com que o sistema o reconheça?

Lembre-se de que os bits setuid e setgid foram inventados para uma finalidade completamente diferente: fazer com que um executável seja executado com o uid ou gid do proprietário, em vez do uid ou gid do usuário que está executando o arquivo. Qualquer outro uso é apenas um recurso extra.

Esses bits não têm função em arquivos comuns que não são executáveis. (E também shell scripts em algumas distros, devido a problemas de segurança.) Originalmente, eles também não tinham função para diretórios. Obviamente alguém decidiu que seria legal usar o setgid não utilizado nos diretórios e usá-lo para reforçar a consistência da propriedade do grupo. Afinal, se você está jogando com a propriedade do grupo, é porque mais de uma pessoa está trabalhando com o arquivo, e provavelmente faz sentido que todos os arquivos em um determinado diretório pertençam ao mesmo grupo, independentemente de quem os criou. Aborrecimentos devido a alguém esquecendo de executar o newgrp são eliminados.

Então, por que não implementar o mesmo recurso para setuid e uid do arquivo? Bem, uid é muito mais básico que gid. Se você implementar isso, geralmente um arquivo não pertencerá ao usuário que o criou! Presumivelmente, o usuário ainda pode modificar o arquivo (supondo que a umask seja algo sensato), mas não pode alterar os bits de permissão. Difícil de ver a utilidade disso.

Acredito que a resposta a esta pergunta esteja relacionada aos problemas de segurança da "distribuição de arquivos" que resultaram na maioria dos sistemas operacionais semelhantes ao Unix modernos, não permitindo a "distribuição de arquivos". "Distribuição de arquivo" é quando um usuário que não é superusuário altera a propriedade de um arquivo para alguém que não seja esse usuário. Esse recurso oferece muitas oportunidades para travessuras.

Como as doações de arquivos não são permitidas, o setuid nos diretórios, que executariam a mesma função em outro formulário, não é permitido ou será ignorado se definido.

Quanto à alteração do comportamento, você precisaria modificar as bibliotecas e utilitários do SO.

Um bom caso de uso para implementá-lo é o seguinte:

Digamos que você tenha um servidor de vários sites com três sites seguros. Você tem 3 grupos criados, um para cada um dos diferentes mantenedores de sites. Todos os arquivos em todos os sites precisam pertencer ao usuário apache, para que o apache possa ler e gravar neles (drupal / wordpress, etc).

Se o setuid, mas funcionou como o bit setgid para permissões de diretórios, seria algo como isto:

/var/www/sitea - apache:groupa  rwS rwS ---
/var/www/siteb - apache:groupb  rwS rwS ---
/var/www/sitec - apache:groupc  rwS rwS ---

Dessa forma, cada grupo de mantenedores tinha acesso para ver e tocar apenas seu conteúdo, mas o usuário do servidor da Web apache poderia servir todo o conteúdo e não é necessário que os usuários se preocupem em alterar a propriedade dos arquivos enviados.

Outro caso de uso é para uploads anônimos de ftp / http ou mesmo sftp / ssh. O grupo e o GID no diretório de upload seriam raiz, assim como o proprietário e o UID. As outras permissões seriam -wx. Isso permitiria que todos escrevessem acesso ao diretório de upload, mas não poderiam ler nada depois que o upload fosse feito e o root possuiria todos os arquivos recém-criados.

Portanto, existem dois casos de uso válidos e perfeitamente bons para habilitar a funcionalidade UID nos diretórios para corresponder ao bit GID.

Steven Mercurio

Um pouco atrasado para a festa, mas no caso de futuros leitores tropeçarem nisso;) Como afirmado por outros, em um sistema de arquivos OS-X padrão, o setUID para diretórios é ignorado - e não parece haver uma maneira fácil de contornar isso ( mount -o.... ou o que não). Como tantas vezes, a página de manual na verdade não está em conformidade com o comportamento do OS-X, literalmente:

4000 (o bit set-user-ID-on-Execution) [...] Diretórios com o set-user-id bit definido forçarão todos os arquivos e subdiretórios criados neles a pertencer ao proprietário do diretório e não a o uid do processo de criação [...]

mas também lista a possibilidade de obter o mesmo efeito sem abrir mão da propriedade original. O Linux usa '[g /] setfacls' para efeitos semelhantes (são permissões que não são realmente visíveis à primeira vista, portanto, às vezes, pode ser um incômodo).

Quanto ao 'como posso obter efeitos semelhantes', leia a página de manual inteira e brinque com:

chmod +a 'guest allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' ./[DIRECTORY]

você pode verificar via

ls -le

se tudo parece bem. Outras opções incluem inserir regras em posições específicas, remover ou substituir regras específicas. As duas opções dignas de nota aqui são " file_inherite directory_inherit" permitindo que as regras sejam anexadas a um novo diretório / arquivo.

Eu não gosto muito de usar o setUID, mas o setGID é muito útil em servidores de arquivos, onde simplesmente definir o grupo 'principal' não funciona ou os clientes têm máscaras de arquivos que não permitem a gravação em grupo. Isso seria resolvido por:

chmod +a 'mygroup allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /fileserver/groupfolders/mygroup

Bem, deve respeitar o padrão. Posso pensar em alguns cenários com o sftp - apenas que isso me salvaria de muitos problemas, tanto com o acl quanto com o conjunto de máscaras acl que o sshd faz, e a redefinição que devo fazer com essa máscara.

A segurança por padrão é bastante útil, mas se você não a fizer, está apenas criando um pesadelo.

https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

De qualquer forma, é como o Linux funciona agora, então use apenas ACLs para solucionar esses problemas.

De acordo com http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories, o bit setuid é ignorado para diretórios nos sistemas UNIX e Linux. É possível fazê-lo agir como você espera no FreeBSD.