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

A especificação POSIX para o chownutilitário menciona em sua seção racional a chown user:groupsintaxe (anteriormente chown user.group) (ênfase minha):

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

• Há casos em que a condição final desejada não pôde ser alcançada usando os utilitários chgrp e chown (que apenas alteraram 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.)

Eu pensei que a user:groupsintaxe era uma coisa de conveniência. Agora, o que precede implica que há coisas que você pode fazer com as chown user:groupquais você não podechgrp group; chown user

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

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

Não entendo o que o proprietário e o proprietário desejado não são membros do grupo atual .

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

O subsistema Microsoft Interix Unix (agora aposentado) para seu kernel NT lidava um pouco diferente com as permissões de usuário e grupo do que outros:

As informações de usuário e grupo são armazenadas no banco de dados do Security Access . Usuários e grupos são armazenados no mesmo banco de dados, mas os nomes de grupos e usuários devem ser exclusivos; nenhum grupo pode ter o nome de um usuário e vice-versa. (Esse 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 . (Scripts de shell de exemplo para criar e remover usuários estão incluídos no diretório /usr/examples/admin.) Os usuários podem pertencer a muitos grupos.

Aqui estão alguns trechos 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.

Usuários e grupos que têm permissão para acessar um objeto são identificados por seus SID. Todos os objetos que podem ser protegidos pelo Windows possuem uma DACL (lista de controle de acesso discricionário), que consiste em entradas separadas chamadas ACEs (entradas de controle de acesso). 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 está chamando o chgrp (1) deve pertencer ao grupo especificado e ser o proprietário do arquivo ou ter privilégios apropriados.

CHOWN

... Os operandos do proprietário e do 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 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 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 motivos de segurança, a propriedade de um arquivo pode ser alterada apenas por um processo com privilégios apropriados.

Enquanto eu leio, isso significa que se sua conta de usuário pertence a um grupo do Windows com privilégios suficientes para modificar as permissões de um arquivo pertencente a esse grupo, é possível efetivamente chgrpesse arquivo fora do controle da sua conta de usuário. Isso equivale a um controle menor do que você pode ter com parâmetros chownexplícitos user:group. Nesse contexto, sem a possibilidade de declarar user: e :group você nunca poderá obter os mesmos resultados do contrário.

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

Aqui está um link para um documento Solaris agora obsoleto que descreve o ajuste rstchownque ...

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

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

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

Essa opção não invalida a conformidade POSIX do Solaris . Só que é uma opção qualifica-a como conforme :

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

As constantes simbólicas a seguir devem ser definidas com um valor diferente de -1. Se uma constante é definido com o valor de zero, as aplicações devem usar os sysconf(), pathconf()ou fpathconf()funções, ou a getconfutilidade, para determinar quais as características estão presentes no sistema em que o tempo ou para o nome do caminho particular em questão.

_POSIX_CHOWN_RESTRICTED

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

A chown()função do sistema - que é a chamada do sistema documentada feita pelos utilitários shell chowne chgrp- é especificada para falhar por vários motivos. 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_RESTRICTED indica que esse privilégio é necessário.

O comportamento de conceder direitos de modificação de permissões a usuários não-root nunca foi exclusivo do Solaris. Há uma cobertura muito excelente - se um pouco datada - de permissões de arquivo Unix nesta postagem do fórum em que o autor declara:

Originalmente, o Unix permitia ao proprietário de um arquivo distribuir 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 essa operação ... O BSD [posteriormente] foi removido chowndos usuários não root ... [em parte porque] ... implementou cotas de disco que poderiam limitar a quantidade de espaço em disco disponível. o usuário poderia ter em um sistema de arquivos ... Usuários mal-intencionados poderiam doar arquivos grandes para passar pelas cotas.

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

Outro post bom - e mais recente - da lista de discussão cita isso e continua:

O padrão da maioria dos sistemas operacionais é para chownser restrito apenas à raiz. E existe um consenso de que deve permanecer assim por considerações de segurança. Se um usuário não raiz 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.

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

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

E como você aponta em 2003 :

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

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

Em qualquer caso em que um usuário não raiz possa manipular as permissões de arquivo, é concebível, como mencionado na lógica citada em sua pergunta, que um usuário possa chownum arquivo que ele possui para que ele seja de propriedade de outro usuário. Se a propriedade do grupo de arquivos e os chowngrupos de usuários não estiverem alinhados, o usuário não poderá mais modificar esse arquivo.

Nesse cenário chown , chgrp falharia, pois o usuário não teria mais permissões para alterar as permissões desse arquivo, enquanto chown user:group- desde que o grupo esteja entre os próprios - teria êxito.

Existem provavelmente muitas outras situações de nicho que possam resultar da mesma forma, que podem incluir diretório pegajoso e / ou setgid pedaços, sistema de arquivos e / ou listas de controle de acesso específicos de implementação. Este tópico é interessante, por exemplo. As inúmeras permutações estão muito além do meu próprio alcance débil - e é por isso que essa resposta é modificada. Se você está lendo isso, acredita que vale a pena melhorar e acredita que sabe - por favor .

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

Nos cabeçalhos da seção POSIX XRAT , Terceiro e Quarto Domínios :

Geralmente, os usuários que especificam a opção para uma travessia da hierarquia de arquivos desejam operar em uma única hierarquia física e, portanto, os links simbólicos, que podem fazer referência a arquivos fora da hierarquia, são ignorados. Por exemplo, o arquivo do proprietário da 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 chown -Rarquivo do proprietário do comando é descrito no terceiro e quarto domínios.

... Há um problema de segurança com o padrão de uma caminhada lógica. Historicamente, o chown -Rarquivo de usuário do comando era seguro para o superusuário porque os bits setuid e setgid 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 pode 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 percorrem a hierarquia para não serem indiretos pelos links simbólicos, e scripts históricos que fazem percursos recursivos se tornariam instantaneamente problemas de segurança. Embora isso seja principalmente um problema para os administradores de sistema, é preferível não ter padrões diferentes para diferentes classes de usuários.

...

Em 4.3 BSD, chgrpdurante o percurso em árvore, o grupo do link simbólico mudou, não o alvo. Os links simbólicos no 4.4 BSD não tinham proprietário, grupo, modo ou outros atributos de arquivo do sistema UNIX padrão.

E a partir da chgrppágina POSIX propriamente dita, há uma que aponta para uma possível -Ração ecursiva incompleta , ou pelo menos para o que costumava ser:

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

Suposição 1: as regras para determinar se são chownbem-sucedidos verificam o usuário-alvo e as partes do grupo de forma independente, ou seja, elas são da forma user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters).

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

Suposição 3: as regras para determinar se os chownsucessos não dependem de qual grupo o arquivo pertence atualmente.

Corolário: se chown(file, uid, gid)fosse bem-sucedido, o faria chown(file, -1, gid) && chown(file, uid, -1).

Eu não sei de uma variante do Unix que viole qualquer uma dessas suposições, elas parecem bastante seguras.

Essa frase tem a aparência de algo que alguém no comitê disse quando estava cansado depois de horas debatendo quantas opções cabiam na cabeça de uma psligação - ou que a secretária maltratou - e que ninguém pegou 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 lógica do POSIX, bem como a atomicidade (ah, se houvesse apenas uma chamada para alterar a propriedade e as permissões )

Um caso em que a suposição 3 pode estar errada está em um sistema em que um processo pode ter a capacidade de alterar os proprietários do arquivo, mas apenas se eles tiverem permissão de gravação no arquivo. Embora um pouco realista, não conheço nenhum sistema em que esse seja o caso. Em seguida, chgrppara um grupo de um processo que a execução nem como raiz nem como o usuário que possui o arquivo pode torná-lo fora do limite para um 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 for bem-sucedida. Este não é um argumento muito convincente, pois envolve diretórios que o proprietário não tem permissão para percorrer, e um aplicativo que desejava proteger contra todos esses casos precisaria mexer nas permissões de qualquer maneira. No entanto, ele atende tecnicamente à condição dessa lógica. Suponha que o processo em execução tenha usuário efetivo alice, grupo efetivo staffe a capacidade de alterar os proprietários de arquivos arbitrariamente (não apenas para denunciá-los; várias variantes do unix possuem esse recurso, embora raramente seja concedido a processos não raiz).

$ 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