O que significa quando um arquivo é de propriedade do usuário “root” e o grupo “root”?

Question

Digamos que temos o seguinte arquivo de propriedade do usuário root e o grupo root :

-rw-r----- 1 root root 54 2017-12-18 04:21 1.txt

E diga que temos um processo com fsuid de root , mas com fsgid de algum outro grupo que não seja root .

As permissões de usuário para o arquivo dizem que o usuário proprietário pode lê-lo e gravar nele, mas não executá-lo. Mas eu acho que como o processo tem fsuid de root , então as permissões do usuário do arquivo não se aplicam ao processo, e assim o processo será capaz de ler e escrever e executar o arquivo, correto? / p>

Agora, digamos que temos um processo com fsgid de root , mas com fsuid de algum outro usuário que não seja root .

As permissões do grupo para o arquivo dizem que o grupo proprietário pode lê-lo, mas não pode escrevê-lo e executá-lo. Agora eu acho que neste caso o processo não tem acesso total ao arquivo e somente as permissões de grupo do arquivo se aplicam ao processo, correto?

    

Answer 1

As regras são as seguintes:

• Se o usuário for o usuário root (UID = 0), conceda acesso total
• Se o usuário for o proprietário, use o triplete do proprietário como permissão
• Se o usuário não for o proprietário, mas pertencer ao grupo, use o trio de grupo como permissão
• Se o usuário não é o proprietário nem o membro do grupo, use o outro trio como permissão

Portanto, para o root, não importa muito, de qualquer forma - mas, para outros usuários, é o tripleto de permissão mais específico que se aplica. Portanto, no seu exemplo, se o usuário é o proprietário e um membro do grupo, é o tripleto do proprietário usado (não o trio de grupo). Então, se o grupo tiver permissão de leitura e gravação, mas o proprietário só tiver permissão de leitura; então o dono só poderá ler o arquivo - mesmo que o seu grupo de membros devesse deixar que ele escrevesse também. Outros membros (não-proprietários) do grupo terão permissão para ler e escrever o arquivo.

O proprietário de um arquivo sempre pode adicionar mais permissões para si mesmo se precisar - e às vezes um programa pode fazer isso por você. Por exemplo, se você tiver um arquivo protegido contra gravação (por exemplo, permissão r - r -----), alguns editores permitirão que você escreva para eles de qualquer maneira (geralmente após uma confirmação). O editor está sendo executado como você e, como você possui o arquivo e pode alterar suas permissões, o editor pode remover a proteção contra gravação e permitir que você salve o arquivo.

+++

Isso significa que é o usuário-raiz que possui o arquivo e obteve permissão para lê-lo e gravá-lo - o proprietário (root) também pode alterar a permissão do arquivo. E que os membros do grupo raiz podem lê-lo. Outros usuários não podem ler, gravar nem executar o arquivo. (Como é um arquivo de texto, provavelmente não faz sentido executá-lo mesmo assim.)

Muitos arquivos em um sistema Linux tem usuário root como proprietário e grupo raiz, como grupo. Embora, tradicionalmente, vários usuários do sistema e grupos de sistemas - como bin, sys, proc, operator - possuíssem muitos arquivos em vez de root. Por exemplo, os binários (os programas executáveis) geralmente tinham bin-user e / ou bin-group como propriedade (por exemplo, bin: bin ou root: bin).

A exceção a isso eram os executáveis que precisavam ser executados como root - eles precisavam pertencer ao usuário root. Normalmente programas executam como / com a permissão de quem quer que tenha executado o programa. Se você executar o comando ls , ele será executado com suas permissões e, portanto, não poderá mostrar diretórios que você não pode listar (como os diretórios de outros usuários). Se um comando é executado com permissão-raiz, por outro lado, ele tem acesso a todo o sistema (é por isso que você não quer isso na maioria dos executáveis).

Um bom exemplo é o passwd -command que permite alterar a senha. Isso é executado como root e dá a qualquer usuário acesso limitado aos arquivos usados para armazenar os bancos de dados de senhas e usuários.

raiz rwsr-xr-x: root / usr / bin / passwd

s = x + S, em que x é permissão de execução, e S é executado como proprietário ou executado como grupo, dependendo se for definido para o proprietário ou grupo tripleto.

Portanto, o usuário root é o proprietário; e tenho permissão para ler, escrever e executar. O grupo-raiz é o grupo e obteve permissão de leitura e execução. Enquanto outros usuários também obtiveram permissões de leitura e execução. Além disso, o executável será executado com as permissões de seu proprietário - ou seja. root - e não com as permissões do usuário que o executa (como é normal), graças ao "s" (u + s) no tripleto do proprietário.

Outro exemplo, desta vez do BSD (um sistema operacional UNIX):

rws-x --- raiz: roda / bin / su

Isso significa que o executável su é sempre executado como proprietário - raiz. Esse usuário root pode ler, escrever e executar. Que os membros do grupo de rodas estão preparados para executá-lo, mas não para lê-lo (por exemplo, copiá-lo). E que outros usuários não podem ler, escrever nem executá-lo. (O comando su existe no Linux também, mas aqui todos os usuários podem executá-lo - ainda assim ele é executado como usuário root.)

Outros programas também podem ser executados como algum usuário do sistema (e grupo) - por exemplo, o apache web-server é frequentemente executado como o www-data-user (e o www-data-group). Dessa forma, ele não pode causar muitos danos se for comprometido, devido à falta de permissões onde ele não pertence.

    

Answer 2

Seu segundo ponto está correto, os membros do grupo root podem ler o arquivo, mas não podem escrevê-lo ou executá-lo.

Seu primeiro ponto está incorreto - até mesmo o usuário root não pode executar este arquivo. root pode facilmente alterar as permissões para torná-lo executável, mas não pode realmente executá-lo até que essa etapa seja executada.

Um aviso importante a ser observado é que, com scripts de shell ou outros scripts de texto simples, eles podem ser "originados" para execução sem o bit executável sendo definido. Neste exemplo, se o conteúdo do arquivo 1.txt for realmente um script bash, mesmo com as permissões 0650, você poderá executar bash 1.txt e ter os comandos dentro do arquivo executados, efetivamente executando o script e parecendo contornar o bit de permissão de execução.

A advertência pode ser vista aqui:

# ./myecho
Hi there!
# chmod -x myecho
# ./myecho
-bash: ./myecho: Permission denied
# sh myecho
Hi there!