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

Question

Eu tenho o seguinte arquivo:

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

Troquei o usuário para root no terminal e observei os seguintes comportamentos:

• Eu posso ler este arquivo e escrever para ele.

• Não consigo executar este arquivo.

• Se eu definir o x bit nas permissões de usuário ( ---x------ ) ou as permissões de grupo ( ------x--- ) ou as outras permissões ( ---------x ) do arquivo, então eu seria capaz para executar este arquivo.

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

    

Answer 1

O acesso privilegiado a arquivos e diretórios é realmente determinado por recursos, não apenas por root ou não. Na prática, root geralmente tem todos os recursos possíveis, mas há situações em que todos / muitos deles podem ser descartados ou outros 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 afetam:

O principal recurso aqui é CAP_DAC_OVERRIDE , um processo que permite msgstr "ignorar ler, gravar e executar verificações de permissão". Isso inclui ler e escrever em qualquer arquivo, assim como ler, escrever e acessar diretórios.

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

Read/write DACs are always overridable. Executable DACs are overridable when there is at least one exec bit set.

E o código verifica se há pelo menos um x bit definido se você está tentando executar o arquivo. Eu suspeito que é apenas um recurso de conveniência, para evitar a execução acidental de arquivos de dados aleatórios e obter erros ou resultados estranhos.

De qualquer forma, se você pode sobrescrever permissões, você pode simplesmente fazer uma cópia executável e executá-la. _{(Embora possa fazer uma diferença na teoria para arquivos setuid de um processo foi capaz de substituir permissões de arquivo ( CAP_DAC_OVERRIDE ), mas não tem outros recursos relacionados ( CAP_FSETID / CAP_FOWNER / CAP_SETUID Mas ter CAP_DAC_OVERRIDE permite editar /etc/shadow e coisas assim, então é aproximadamente igual a ter acesso root completo de qualquer maneira.)}

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

Substituir o bit fixo nos diretórios é mencionado apenas em CAP_FOWNER , então parece que CAP_DAC_OVERRIDE não seria suficiente para ignorar isso. (Isso lhe daria permissão de escrita, mas geralmente em diretórios fixos você tem isso de qualquer maneira, e +t limita isso.)

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

É claro que ainda há situações em que até os recursos não ajudam a modificar os arquivos:

• alguns arquivos em /proc e /sys , pois não são arquivos reais
• SELinux e outros módulos de segurança que podem limitar a raiz
• chattr imutável +i e anexe apenas +a flags no ext2 / ext3 / ext4, ambos os quais param até mesmo o root, e também previnem renomeação de arquivos, etc.
• sistemas de arquivos de rede, em que o servidor pode fazer seu próprio controle de acesso, por exemplo, root_squash na raiz de mapas do NFS para ninguém
• FUSE, que eu suponho que poderia fazer qualquer coisa
• montagens somente leitura
• dispositivos somente leitura

Answer 2

Isso é exatamente como você observou para as permissões padrão:

• Leia & escreva:
  Por padrão, o usuário root pode acessar qualquer arquivo no sistema. Você pode remover esse acesso alterando os atributos como explicado aqui: chattr . Isso é vinculado a 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.

Answer 3

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 tem um recurso irrestrito para modificar esse 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)

    

Answer 4

Deixe-me explicar você teoricamente.

root user is the king of the operating system.

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 possuir o arquivo, o root também poderá executar o arquivo.

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

    

Answer 5

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

As permissões de leitura e gravação são usadas para impor políticas de segurança. O usuário root é geralmente imune a restrições de segurança (há 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 é o "superusuário". / p>

A permissão de execução é mais um modo consultivo, distinguindo se o arquivo é pretendido para ser executável ou apenas dados. Por causa disso, 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. Naturalmente, 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 quiser (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 tem uma linha #! , você pode executá-lo como um programa - o interpretador nomeado no shebang é executado com o nome do arquivo como argumento. Mas isso só será feito quando a permissão de execução estiver definida. Por outro lado, você pode simplesmente executar o interpretador diretamente, por exemplo %código%. Os intérpretes só se importam se conseguem ler o arquivo, eles não verificam as permissões de execução.