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


18

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?


11
@ Robert, em que sistema essas regras se aplicam? Nos sistemas que eu conheço, você é root e pode fazer o que quiser ou não é o usuário1 e não pode fazer nada. Se você for usuário1, dependendo do sistema, não poderá alterar o proprietário de qualquer maneira ou, quando puder, poderá alterar o grupo para o que quiser e, em seguida, o usuário para o que quiser.
Stéphane Chazelas

Se eu tiver um diretório que possuo, um arquivo pertencente a outra pessoa e um grupo do qual não sou membro, mas posso ler devido a outras permissões. Então, é possível copiá-lo para me tornar o proprietário, e ele tem um novo grupo (do qual sou membro). Portanto, deve ser tão salvador para o sistema operacional permitir-me como não-root chown me:my-group filese o arquivo estiver em um local onde eu tenha acesso de leitura / gravação (sem aderência). Eu não poderia chgrp primeiro como não proprietário. Não pude mostrar primeiro, pois isso resultaria em um arquivo que não pude criar: possuindo um arquivo com o grupo do qual não sou membro.
CTRL-ALT-DELOR

@richard, não, não seria tão seguro . Esse arquivo pode ser vinculado a outro diretório ao qual você não tem acesso. Em sistemas nos quais você pode vincular arquivos que não possui (como o Linux por padrão), isso significa que você pode reivindicar a propriedade de qualquer arquivo vinculando-o a um diretório ao qual você tem acesso de gravação.
Stéphane Chazelas

Encontrei este texto e também explica por que estou errado (não é tão seguro): “Se você tivesse permissão para se apropriar do arquivo, isso seria uma falha de segurança. Por exemplo, o usuário que alguém poderia abrir o arquivo, verifique sua propriedade e permissões (chamando fstat no identificador de arquivo aberto) e conclua que apenas um programa em execução como alguém poderia ter produzido esses dados. Se você fosse capaz de apropriar-se do arquivo, você poderia, então, mudar o seu conteúdo contra a vontade de alguém.”- unix.stackexchange.com/questions/68439/...
ctrl-alt-Delor

Respostas:


5

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.


11
@StephaneChazelas - feliz que você tenha entendido. “Isso é bagunça do kinduva, porque eu não sou muito bom com toda a coisa das permissões - especialmente quando os atributos do SE estão envolvidos. A conexão está solta - links! = Ch {grp, own}, mas imaginei que os caras do POSIX se esforçariam demais para explicá-la (há também um grande gráfico na página), pelo mesmo motivo que um link pode causar problemas, então duas ações -R podem ocorrer. Não quebraria nada se você colocasse os dois pés - usuário e grupo - como você diz, mas se você já estiver 1 desligado. Não é realmente o meu forte. Desculpe.
mikeserv

11
Bom ponto, eu não tinha pensado em -R. Pode-se imaginar que você pode perder o acesso de pesquisa ou leitura a um diretório no chgrp, o que impediria que você alterasse as permissões de arquivos, mas, novamente, com as formas tradicionais do Unix de lidar com propriedade ou permissões, não vejo como fazer acontecer. Uma outra pena área investigando Eu acho que seria o ACLs NFSv4 em sistemas que o suportam (Solaris, FreeBSD, SUSE ...)
Stéphane Chazelas

@ StéphaneChazelas - existe algum aspecto da sua pergunta que este post não responde?
mikeserv

muito obrigado por essa pesquisa completa. Seria bom se você pudesse adicionar um exemplo ao subsistema NT Unix, onde o texto POSIX se aplica. Mas não tenho certeza de como as recompensas funcionam com as respostas do wiki da comunidade. Vou dar uma chance.
Stéphane Chazelas

@ StéphaneChazelas - Eu não ligo para os pontos e nunca o fiz. Eu só esperava não estragar tudo. Eu não estou surpreso, eu entendo a parte boa - você quer dizer NT Unix 4? Documentação oficial da Microsoft afirmam conformidade POSIX, pelo menos para quando ele ainda era Interix, eu e afirmam um pouco estranha chgrp chown... não pode se comportar como você espera ...
mikeserv

1

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

Observe que o POSIX não é apenas sobre o Unix. Existem muitos sistemas operacionais não Unix que possuem um subsistema / API POSIX (por exemplo, Microsoft Windows NT). Não sei se essas condições são suficientes para reivindicar o corolário. O chgrpou chownpode ter efeitos colaterais que afetam a capacidade de executar o outro. Por exemplo, chownremove a capacidade de chgrp, isso é um fato. chgrplimpa o setuid / setgid bit, pode limpar alguma forma de ACL ou outra forma de contexto de segurança ...
Stéphane Chazelas

@ StéphaneChazelas Concordamos que o chownseguido por chgrppode falhar, mas a pergunta é sobre chgrpseguida por chown. Hmmm, contexto de segurança ... talvez em um sistema com controle de acesso obrigatório, chgrppossa manchar um arquivo e torná-lo não mais chownable? Isso parece absurdo.
Gilles 'SO- stop be evil'

Talvez não muito longe. Eu não sei muito sobre ACLs NFSv4 / WinNT, mas suspeito que há algo que poderia fazer esse tipo de coisa acontecer (e / ou invalidar sua terceira suposição). Ainda assim, esse texto é bastante específico e quem o escreveu teria um exemplo específico em mente. Talvez tenha sido escrito por algumas pessoas da Microsoft.
Stéphane Chazelas

re sua edição mais recente. Com chown -R bob: estudantes, alice ainda perderia as permissões de pesquisa dir, para que isso funcionasse, chownseria necessário primeiro processar a profundidade dos arquivos e não conheço nenhuma implementação que faça isso. Portanto, é um caso quase válido em que chgrp + chown falharia onde chmod u: g não poderia, mas isso não corresponde ao texto da justificativa.
Stéphane Chazelas

A assinatura incorreta da secretária e as chownteorias recursivas de primeira linha parecem conflitar.
mikeserv
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.