Quais são as permissões de root para um arquivo?

Question

Se eu digitar:

ls -l file.txt

Vejo que os direitos desse arquivo são equivalentes a "456":

• 4 = proprietário (r -)
• 5 = grupo (r-x)
• 6 = outros (rw -)

Quais são os direitos de root neste caso? Tem 777?

Os direitos podem ser alterados para que a raiz tenha menos permissões do que o proprietário?

    

Answer 1

Eu checaria esta página fora . Ele fala sobre permissões de arquivos em profundidade.

Mas, para responder à sua pergunta diretamente, não:

The super user "root" has the ability to access any file on the system.

No seu exemplo, por exemplo, se o arquivo pertencer a bob e o proprietário do grupo também for bob , você verá algo assim:

-r--r-xrw-. 1 bob bob 8 Jan 29 18:39 test.file

O terceiro grupo de bits, o (rw), também se aplica à raiz, já que a raiz faz parte do grupo others . Se você tentou editar o arquivo como root, verá que não há problema em fazê-lo.

Mas para testar sua teoria ainda mais, se o arquivo fosse de propriedade do root:

-r--r-xrw-. 1 root root 8 Jan 29 18:40 test.file

E você foi novamente editar o arquivo, veria que ainda não tem problemas para editá-lo.

Finalmente, se você fez o extremo:

chmod 000 test.file
ls -lh test.file
----------. 1 root root 8 Jan 29 18:41 test.file

E você foi novamente para editar o arquivo que você veria (pelo menos no vi / vim) "test.file" [readonly] . Mas você ainda pode editar o arquivo e forçar a salvá-lo com :wq! .

Teste @ Stéphane Chazelas com um arquivo de script de shell:

#!/bin/sh

echo "I'm alive! Thanks root!"

[root ~]# ls -lh test.sh
----------. 1 atgadmin atgadmin 31 Jan 30 10:59 test.sh

[root ~]# ./test.sh
-bash: ./test.sh: Permission denied

[root ~]# sh test.sh
I'm alive! Thanks root!

@Shadur já disse isso, então vou citar em vez de reafirmar:

Note: The execution bit is checked for existence, not whether it's applicable to root.

    

Answer 2

O Root tem acesso total a todos os arquivos no sistema por design. Se você estiver procurando proteger um arquivo da exclusão acidental, use

chattr +i file

Isto irá definir o sinalizador imutável no GNU / Linux. Você pode removê-lo com -i em vez de +i .

No FreeBSD, você pode usar

chflags schg file

Substitua noschg por schg para desfazê-lo.

Se você deseja proteger um arquivo de ser visível para o root, você deve armazenar seu arquivo em um sistema diferente ou usar a criptografia como último recurso.

Veja também: link

    

Answer 3

Could the rights be changed so that the root will have less permissions than the owner?

É fácil, basta alterar o arquivo passwd para que o uid do root não seja zero. Por outro lado, não faça isso, é má ideia.

Você não é a primeira pessoa a fazer essa pergunta, e algumas dessas pessoas tiveram a ideia de recursos, mas vamos começar com isso em pouco tempo, primeiro vamos começar entendendo o funcionamento do sistema de permissões.

Para iniciar a parte do computador que acessa as verificações não sabe seu nome, ele conhece você por número e esse número é chamado de uid ou identificador de usuário. de uma forma semelhante, não sabe os nomes dos grupos dos quais você é membro, apenas o gid. o mapeamento entre uid e name está no arquivo passwd e o gid é mapeado no arquivo groups.

Agora, quando você deseja abrir um arquivo, são feitas quatro verificações: você tem permissão para pular as verificações, é permitido a um usuário, é um membro de um grupo permitido e, como alguém mais você tem permissão para. Eu estou pulando algumas coisas aqui como switch de serviço de nome e listas de controle de acesso e leitura de execução de gravação, mas a parte que você está interessado é o primeiro teste.

Às vezes, você pode pular os testes de permissão de arquivo. Por quê? e (muito importante) Quando? Agora há algumas coisas que às vezes precisam ser feitas que você não quer que ninguém faça e não se encaixam no modelo de permissão de arquivo muito bem. Todos os tipos de coisas, como abrir uma conexão de rede em uma porta baixa, montar uma partição ou ignorar as verificações de permissão. Hoje em dia essas coisas são conhecidas como capacidades. Antigamente, o UID0 tinha tudo isso e não havia nada que você pudesse fazer sobre isso, hoje em dia você pode fornecer recursos a outros usuários ou soltá-los, mas o padrão é o comportamento antigo.

A outra maneira de restringir a raiz é com algo como o selinux, mas isso é outra bola de cera.

    

Answer 4

As respostas anteriores supõem que o root tenha acesso total a tudo. Embora isso seja verdade na maioria das variantes do Unix, isso é parcialmente verdadeiro nos modernos (desde o final dos anos 90; kernel 2.2) os kernels do Linux. No Linux moderno, os privilégios elevados são controlados por um modelo de recursos. Por padrão, o kernel concede todos os recursos a um programa se ele estiver sendo executado como UID 0. Um desses recursos é o DAC_OVERRIDE, que substitui as permissões de controle de acesso discricionário (AKA). Isso é relevante porque, em um sistema 2.6.26 ou posterior (portanto, os sistemas Linux não embarcados mais atualizados agora), há um sinalizador securebits que pode ser configurado para desativar alguns ou todos os recursos fornecidos aos aplicativos que mudar para a raiz ou que começam como root. Para saber o que o UID 0 pode fazer, você tecnicamente precisa saber quais recursos podem ser herdados por processos executados como UID 0.

Então, o geralmente root pode fazer o que quiser. Mas, se você está escrevendo um programa que precisa fazer coisas "como root" no Linux, você realmente precisa se familiarizar com o modelo de capacidades e as funções associadas a ele. Não seja como muitos fornecedores que escrevem coisas que "precisam" executar o suid root apenas para abrir um arquivo ou abrir um soquete bruto; defina as capacidades que seu programa precisa e teste essas coisas. man capabilities .

    

Answer 5

Which the rights for root in this case? Does it have 777?

Sim.

Como já foi dito, as permissões de leitura e gravação não são aplicadas para o root. No entanto, a permissão de execução ainda é verificada quanto à presença, portanto, o root não poderá executar o arquivo se nenhum sinalizador de execução tiver sido definido. Este não é o caso aqui, pois o grupo tem o sinal x .

Observe também que, independentemente de a permissão de gravação ser concedida ou não, root ou qualquer um terá o acesso de gravação recusado a um arquivo armazenado em um sistema de arquivos somente leitura.

A raiz também pode ter menos direitos que o proprietário se o arquivo estiver armazenado em um diretório montado remotamente, como o NFS.

Por fim, observe que as permissões de links simbólicos são essencialmente sem sentido.