Como as permissões de arquivo funcionam para o usuário "root"?

Eu tenho o seguinte arquivo:

---------- 1 Steve Steve 341 2017-12-21 01:51 myFile.txt

Troquei o usuário rootno terminal e percebi os seguintes comportamentos:

• Eu posso ler este arquivo e escrever nele.

• Não consigo executar este arquivo.

• Se eu definir o xbit nas permissões de usuário ( ---x------) ou permissões de grupo ( ------x---) ou outras permissões ( ---------x) do arquivo, seria possível executá-lo.

Alguém pode me explicar ou me indicar um tutorial que explica todas as regras que se aplicam quando o rootusuário está lidando com arquivos e diretórios?

O acesso privilegiado a arquivos e diretórios é realmente determinado pelos recursos, não apenas por ser rootou não. Na prática, rootgeralmente possui todos os recursos possíveis, mas há situações em que todos / muitos deles podem ser descartados ou alguns dados a outros usuários (seus processos).

Em resumo, você já descreveu como as verificações de controle de acesso funcionam para um processo privilegiado. Veja como os diferentes recursos realmente o afetam:

A principal capacidade aqui éCAP_DAC_OVERRIDE um processo que pode "ignorar a leitura, gravação e execução de verificações de permissão". Isso inclui ler e gravar em qualquer arquivo, além de ler, escrever e acessar diretórios.

Na verdade, ele não se aplica à execução de arquivos que não estão marcados como executáveis. O comentário emgeneric_permission ( fs/namei.c), antes do acesso procurar arquivos, diz que

Os DACs de leitura / gravação são sempre substituíveis. Os DACs executáveis ​​são substituíveis quando há pelo menos um conjunto de bits exec.

E o código verifica se há pelo menos um xbit definido se você estiver tentando executar o arquivo. Suspeito que seja apenas um recurso de conveniência, para impedir a execução acidental de arquivos de dados aleatórios e a obtenção de erros ou resultados ímpares.

De qualquer forma, se você puder substituir as permissões, poderá fazer uma cópia executável e executá-la. _{(Embora possa fazer a diferença na teoria para arquivos setuid de um processo era capaz de substituir permissões de arquivo ( CAP_DAC_OVERRIDE), mas não tem outras capacidades relacionadas ( CAP_FSETID/ CAP_FOWNER/ CAP_SETUID). Mas ter CAP_DAC_OVERRIDEpermite editar /etc/shadowe coisas assim, então é aproximadamente igual apenas tendo acesso root completo de qualquer maneira.)}

Há também o CAP_DAC_READ_SEARCHrecurso que permite ler qualquer arquivo e acessar qualquer diretório, mas não para executar ou gravar neles; e CAP_FOWNERisso permite que um processo faça coisas que normalmente são reservadas apenas ao proprietário do arquivo, como alterar os bits de permissão e o grupo de arquivos.

A substituição do bit pegajoso nos diretórios é mencionada apenas em baixo CAP_FOWNER, portanto parece que CAP_DAC_OVERRIDEnão seria suficiente ignorar isso. (Isso daria a você permissão de gravação, mas geralmente em diretórios fixos você a possui de qualquer maneira e a +tlimita.)

_{(Eu acho que dispositivos especiais contam como "arquivos" aqui. Pelo menos generic_permission()só tem uma verificação de tipo para diretórios, mas não verifiquei fora disso.)}

Obviamente, ainda existem situações em que nem os recursos o ajudarão a modificar arquivos:

• alguns arquivos /proce /sys, como eles não são arquivos reais
• SELinux e outros módulos de segurança que podem limitar a raiz
• chattrimutável +ie anexa apenas +asinalizadores no ext2 / ext3 / ext4, os quais param o root e impedem também a renomeação de arquivos etc.
• sistemas de arquivos de rede, nos quais o servidor pode fazer seu próprio controle de acesso, por exemplo, root_squashnos mapas NFS raiz de ninguém
• FUSE, que eu suponho que poderia fazer qualquer coisa
• montagens somente leitura
• dispositivos somente leitura

É exatamente como você notou nas permissões padrão:

• Leitura e gravação:
  por padrão, o usuário root pode acessar qualquer arquivo no sistema. Você pode remover esse acesso alterando atributos como explicado aqui: chattr . Isso é então vinculado aos recursos.

• Executar: o
  usuário raiz não tem permissão de execução, a menos que pelo menos um dos bits de execução esteja definido.

O myFile.txté obtido por chmod 000 myFile.txt.

0 no permission
1 execute
2 write
3 execute + write
4 read 
5 read + execute
6 read + write
7 all

--------- significa que não há permissão para usuário, grupo e outros.

O usuário root possui um recurso irrestrito para modificar este arquivo. A leitura / gravação é concedida. Para executar este arquivo, o usuário root precisa torná-lo executável de qualquer maneira. (chmod 100, 010 ou 001)

O modo de execução é tratado um pouco diferente dos outros modos.

Permissões de leitura e gravação são usadas para impor políticas de segurança. O rootusuário geralmente é imune a restrições de segurança (existem algumas exceções, como arquivos imutáveis, e recursos modernos como recursos tornaram isso mais refinado), e é por isso que outro nome para essa conta é "superusuário".

Permissão de execução é mais um modo de aviso, distinguir se o arquivo é destinado para ser executável ou é apenas dados. Por esse motivo, até o usuário root obedece - não faz sentido executar um arquivo de dados. Se nenhuma das permissões de execução estiver definida, o root não poderá executar o arquivo; se algum deles estiver definido, ele pode. Obviamente, como o root também tem permissão para alterar as permissões de qualquer arquivo, a conta pode tornar um arquivo executável se desejar (a menos que o sistema de arquivos seja somente leitura).

BTW, scripts são um caso interessante nisso. Scripts são arquivos de dados para o intérprete relevante. Se o script tiver uma #!linha, você poderá executá-lo como um programa - o intérprete nomeado no shebang é executado com o nome do arquivo do script como argumento. Mas isso só será feito quando a permissão de execução estiver definida. Por outro lado, você pode executar o intérprete diretamente, por exemplo /bin/bash scriptname. Os intérpretes só se importam se conseguem ler o arquivo, não verificam as permissões de execução.

Deixe-me explicar você teoricamente.

usuário root é o rei do sistema operacional.

Se um arquivo ou diretório tiver alguma permissão como X para executar, mas nada mais e alguém como o usuário Steve tiver o arquivo, o root também poderá executá-lo.

Lembre-se sempre, no Linux root pode fazer qualquer coisa, não há restrições no root.