explicação sobre chown(1) especificação POSIX

Question

A especificação POSIX para o chownutilitáriomenciona em seujustificativaseçãosobre a chown user:groupsintaxe (anteriormente chown user.group) (ênfase minha):

O método 4.3 BSD para especificar proprietário e grupo foi incluído neste volume do POSIX.1-2008 porque:

• Há casos em que a condição final desejada não pode ser alcançada usando os utilitários chgrp e chown (que apenas alteram o ID do usuário).(Se o proprietário atual não for membro do grupo desejado e o proprietário desejado não for membro do grupo atual, a função chown() poderá falhar, a menos que o proprietário e o grupo sejam alterados ao mesmo tempo.)

Achei que a user:groupsintaxe era uma coisa conveniente. Agora, o que foi dito acima implica que há coisas que você pode fazer chown user:groupe que não podechgrp group; chown user

Agora esse texto não faz sentido para mim. No 4.3BSD, apenas o root poderia alterar o proprietário de um arquivo, portanto, em qualquer caso, não há restrição no que ele pode fazer.

SysV e alguns outros sistemas permitem (ou costumavam permitir) que o proprietário de um arquivo alterasse o usuário e o grupo de um arquivo para qualquer coisa, mas mesmo nesses sistemas, o texto acima não faz sentido para mim. OK, se alguém fizer um chown someone-else the-file, não poderá fazer chgrp something-else the-filedepois porque não será mais o dono do arquivo, mas não há nada que o impeça de fazer o chgrpprimeiro (permanecer o dono do arquivo) e chowndepois, e não é isso que o o texto acima está dizendo exatamente.

Eu não entendo o quee o proprietário desejado não é membro do grupo atualtem a ver com o problema.

Então, quais são as condições para as quaisa função chown() pode falhar a menos que o proprietário e o grupo sejam alterados ao mesmo tempoe em qual sistema?

Answer 1

OSubsistema Microsoft Interix Unix (agora aposentado)pois seu kernel NT lidava de maneira um pouco diferente com as permissões de usuários e grupos do que alguns outros:

As informações do usuário e do grupo são armazenadas noBanco de dados de acesso de segurança. Tanto os usuários quanto os grupos são armazenados no mesmo banco de dados, mas os nomes dos grupos e dos usuários devem ser exclusivos; nenhum grupo pode ter um nome de usuário e vice-versa.(Este banco de dados substitui os arquivos /etc/passwde /etc/groupsno UNIX.)Usuários e grupos são criados usando a metodologia apropriada do Windows(Gerenciador de usuários, usuários e computadores do Active Directory ou usuários e grupos locais)ou com o net usercomando Win32.(Exemplos de scripts de shell para criar e remover usuários estão incluídos no diretório /usr/examples/admin.)Os usuários podem pertencer a vários grupos.

Aqui estãoalgunstrechos manuais mais específicos:

No Windows, um usuário ou um grupo pode possuir um objeto. Isso é diferente do UNIX, no qual apenas um usuário possui um objeto.

O Windows identifica todos os usuários e grupos internamente usando um identificador de segurança(SID). Um algoritmo de hash gera valores SID exclusivos; dois usuários ou grupos não terão o mesmo SID.

Os usuários e grupos que têm permissão para acessar um objeto são identificados pelo seu SID. Todos os objetos que podem ser protegidos pelo Windows possuem uma lista de controle de acesso discricionário (DACL), que consiste em entradas separadas chamadas entradas de controle de acesso (ACEs). Uma ACE inclui duas informações importantes: um SID de usuário ou grupo e uma descrição de quanto acesso o usuário ou grupo individual tem a um objeto.

CHGRP

...Altere o ID do grupo para o arquivo... o usuário que invoca chgrp(1) deve pertencer ao grupo especificado e ser o proprietário do arquivo, ou ter privilégios apropriados.

CHOWN

...Os operandos proprietário e grupo são opcionais; no entanto, um deve ser especificado. Se o operando do grupo for especificado, ele deverá ser precedido por dois pontos (:).

O proprietário pode ser especificado por um ID de usuário numérico ou por um nome de usuário. Se um nome de usuário também for um ID de usuário numérico, o operando será usado como um nome de usuário. O grupo pode ser um ID de grupo numérico ou um nome de grupo. Se um nome de grupo também for um ID numérico de grupo, o operando será usado como um nome de grupo.

Por razões de segurança, a propriedade de um arquivo só pode ser alterada por um processo com privilégios apropriados.

Pelo que li, isso significa que, se sua conta de usuário pertencer a um grupo do Windows com privilégios suficientes para modificar as permissões de um arquivo pertencente a esse grupo, será possível efetivamente excluir chgrpesse arquivo fora do controle de sua conta de usuário. Isso equivale a menos controle do que você poderia ter com parâmetros chownexplícitos user:group. Nesse contexto, sem a possibilidade de declararuser: e :groupvocê nunca poderia alcançar os mesmos resultados que de outra forma.

Aqui está um linkpara uma visão detalhada de como o Interix interage com as ACLs do Windows, com foco em como esse conhecimento pode ser aplicado aos sistemas de arquivos Samba em outras variantes do Unix.

Aqui está um linkpara um agoraobsoletoDocumento Solaris descrevendo o ajustável rstchownque...

Indica se a semântica POSIX para a chown(2)chamada do sistema está em vigor...

Aparentemente, se o parâmetro estiver definido com um valor de 0...

...desativar a semântica POSIX abre o potencial para várias falhas de segurança. Também abre a possibilidade de umusuário alterando a propriedade de um arquivo para outro usuário e não conseguindo recuperar o arquivode volta sem intervenção do usuário ou do administrador do sistema.

Tal opção não invalida a opção do SolarisConformidade POSIX. O simples fato de ser uma opção já a qualifica comocompatível:

Embora todas as implementações em conformidade com POSIX.1-2008 suportem todos os recursos descritos abaixo, pode haverprocedimentos de configuração dependentes do sistema ou do sistema de arquivos que podem remover ou modificar qualquer um ou todos esses recursos. Tais configurações não devem ser feitas se for necessária uma conformidade estrita.

As seguintes constantes simbólicas devem ser definidas com um valor diferente de -1. Se uma constante for definida com o valor zero, os aplicativos deverão usar as funções sysconf(), pathconf(), ou fpathconf(), ou o getconfutilitário, para determinar quais recursos estão presentes no sistema naquele momento ou para o nome de caminho específico em questão.

_POSIX_CHOWN_RESTRICTED

O uso de chown()é restrito a um processo com privilégios apropriados e à alteração do ID de grupo de um arquivo apenas para o ID de grupo efetivo do processo ou para um de seus IDs de grupo suplementares.

A chown()função do sistema - que é a chamada de sistema documentada feita tanto pelochownechgrputilitários shell - éespecificado para falharpor inúmeras razões. Entre eles:

EACCES A permissão de pesquisa é negada em um componente do prefixo do caminho.

ELOOP Existe um loop nos links simbólicos encontrados durante a resolução do argumento do caminho.

EPERM O ID do usuário efetivo não corresponde ao proprietário do arquivo ou o processo de chamada não possui privilégios apropriados e_POSIX_CHOWN_RESTRICTEDindica que tal privilégio é necessário.

Entretanto, o comportamento de conceder direitos de modificação de permissões a usuários não-root nunca foi exclusivo do Solaris. Hámuito excelente- se um pouco desatualizado - cobertura de permissões de arquivos Unix emesta postagem no fórumem que o autor afirma:

Originalmente, o Unix permitia que o proprietário de um arquivo distribuísse um arquivo. O proprietário de um arquivo pode mudar o proprietário para outra pessoa. Não havia como um usuário não root desfazer esta operação... BSD[mais tarde]removido chownde usuários não root...[em parte porque]...ele implementou cotas de disco que poderiam limitar quanto espaço em disco um usuário poderia ter em um sistema de arquivos... Usuários mal-intencionados poderiam doar arquivos grandes para escapar das cotas.

Hoje, não é fácil dizer se um não-root pode chownum arquivo. Muitas versões do Unix permitemamboscomportamentos...

Outro bom - e mais recente -postagem na lista de discussãocita isso e continua:

O padrão com a maioria dos sistemas operacionais é chownrestringir apenas ao root. E há um consenso de que deveria permanecer assim por questões de segurança. Se um usuário não-root alterar o proprietário de um arquivo e qualquer bit de execução estiver ativado, os bits SUIDe SGIDdeverão ser limpos. Isso pode ou não acontecer com root.

Acho que o último parágrafo diz isso muito bem.

Esse artigo também faz referência CAP_CHOWNao controle desse recurso no Linux(isso deve afetar apenas o POSIX_CHOWN_RESTRICTEDcomportamento). Há também a CAP_FOWNERcapacidade, que tem um comportamento um pouco diferente.

E comovocê aponta em 2003:

Observe que pelo menos no HPUX, você pode alterar o proprietário dos seus arquivos(para rootpor exemplo)mesmo se você não for um usuário privilegiado...

...que dependia de um setprivgroupparâmetro de configuração.

Em qualquer caso em que um usuário não-root possa manipular as permissões de arquivo, é concebível, como é mencionado nojustificativacitado na sua pergunta, que um usuário pode ter chownum arquivo de propriedade desse usuário para que seja propriedade de outro usuário. Se a propriedade do grupo do arquivo e os chowngrupos do usuário ing não estiverem alinhados, o usuário não será mais capaz de modificar esse arquivo.

Neste cenáriochown então chgrpfalharia porque o usuário não teria mais permissões para alterar as permissões desse arquivo, enquanto chown user:group- contanto quegrupoestá entre os do próprio usuário - teria sucesso.

Háprovavelmenteinúmeras outras situações de nicho que podem resultar de forma semelhante, que podem incluir diretóriopegajosoe/ousetgidbits, sistema de arquivos e/ou listas de controle de acesso específicas de implementação.Este tópicoé interessante, por exemplo. As inúmeras permutações estão muito além do meu fraco entendimento - e é por isso que esta resposta é wikied. Se você está lendo isso, você acredita que vale a pena melhorar e acredita que sabe como -por favor faça.

Há também uma extensa documentação sobre os vários efeitos possíveis de permissões de arquivo, passagem de árvore e links simbólicos que podem causar uma falha semelhante em relação a aplicativos -Recursivos chownaqui:

DeXRAT POSIXtítulos de seçãoTerceiroeQuartos Domínios:

Geralmente, os usuários que especificam a opção para uma travessia de hierarquia de arquivos desejam operar em uma única hierarquia física e, portanto, links simbólicos, que podem fazer referência a arquivos fora da hierarquia, são ignorados. Por exemplo, o arquivo do proprietário chown é uma operação diferente do mesmo comando com a opção -R especificada. Neste exemplo, o comportamento do comando chown owner fileé descrito aqui, enquanto o comportamento do comandochown -Rarquivo proprietário é descrito no terceiro e quarto domínios.

...Há um problema de segurança ao optar por uma caminhada lógica. Historicamente, o comandochown -Ro arquivo do usuário foi seguro para o superusuário porquesetuidesetgidbits foram perdidos quando a propriedade do arquivo foi alterada. Se a caminhada fosse lógica, alterar a propriedade não seria mais seguro porque um usuário poderia ter inserido um link simbólico apontando para qualquer arquivo na árvore. Novamente, isso exigiria a adição de uma opção aos comandos que fazem travessia de hierarquia para não serem indiretos por meio de links simbólicos, e scripts históricos que fazem caminhadas recursivas se tornariam instantaneamente problemas de segurança. Embora isso seja principalmente um problema para administradores de sistema, é preferível não ter padrões diferentes para diferentes classes de usuários.

...

No 4.3 BSD, chgrpdurante a travessia da árvore mudou o grupo do link simbólico, não o alvo. Links simbólicos no BSD 4.4 não tinham proprietário, grupo, modo ou outros atributos de arquivo de sistema UNIX padrão.

E do POSIXchgrppágina propriamente dita, há isto que aponta para uma possível -Ração ecursiva incompleta, ou pelo menos para o queusadoser:

As versões System V e BSD usam diferentes códigos de status de saída. Algumas implementações usaram o status de saída como uma contagem do número de erros ocorridos; esta prática é impraticável, pois pode ultrapassar o intervalo de valores válidos de status de saída. Os desenvolvedores padrão optaram por mascará-los especificando apenas 0 e >0 como valores de saída.

Answer 2

Suposição 1: as regras para determinar se chowno sucesso verifica o usuário alvo e as partes do grupo de forma independente, ou seja, elas estão no formato user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters).

Suposição 2: chown(file, -1, -1)sucesso.

Suposição 3: as regras para determinar se chowno arquivo foi bem-sucedido não dependem do grupo ao qual o arquivo pertence atualmente.

Corolário: se chown(file, uid, gid)tivesse sucesso, então também teria chown(file, -1, gid) && chown(file, uid, -1).

Não conheço nenhuma variante do Unix que viole qualquer uma dessas suposições, elas parecem bastante seguras.

Esta frase parece algo que alguém do comitê disse quando estava cansado depois de horas debatendo quantas opções caberiam no cabeçalho de uma pschamada - ou que a secretária transcreveu incorretamente - e que ninguém percebeu durante a revisão. Afinal, existem outros bons motivos para permitir que o usuário e o grupo sejam alterados automaticamente, incluindo o motivo de desempenho também citado na justificativa POSIX, bem como a atomicidade (ah, se ao menos houvesse uma única chamada para alterar propriedade e permissões ).

---

Um caso em que a suposição 3 pode estar errada é em um sistema onde um processo pode obter a capacidade de alterar os proprietários do arquivo, mas somente se tiver permissão de gravação no arquivo. Embora um tanto realista, não conheço nenhum sistema em que esse seja o caso. Em seguida, chgrppara um grupo de um processo que não está sendo executado nem como root nem como o usuário proprietário do arquivo, pode tornar o arquivo fora do limite para uso posterior chown.

---

Para uma chamada recursiva, há casos extremos em que uma passagem inteira chgrpseguida por uma passagem inteira chownpode falhar quando uma única passagem seria bem-sucedida. Este não é um argumento muito convincente porque envolve diretórios que o proprietário não tem permissão para percorrer, e um aplicativo que quisesse se proteger contra todos esses casos precisaria mexer nas permissões de qualquer maneira. No entanto, tecnicamente cumpre a condição desta lógica. Suponha que o processo em execução tenha user efetivo alice, group efetivo staffe a capacidade de alterar os proprietários dos arquivos arbitrariamente (não apenas para distribuí-los; diversas variantes do Unix têm essa capacidade, embora raramente seja concedida a processos não-root).

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied