Se eu digitar:
ls -l file.txt
Vejo que os direitos desse arquivo são equivalentes a "456":
- 4 = proprietário (r--)
- 5 = grupo (rx)
- 6 = outros (rw-)
Quais são os direitos pararaiznesse caso? Tem 777?
Os direitos poderiam ser alterados para que o root tenha menos permissões que o proprietário?
Responder1
eu verificariaesta página fora. Ele fala detalhadamente sobre permissões de arquivo.
Mas para responder diretamente à sua pergunta, não:
O superusuário “root” tem a capacidade de acessar qualquer arquivo do sistema.
No seu exemplo, por exemplo, se o arquivo pertencer a say bobe 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 grupo de terceiro bit (rw) também se aplicaria ao root, já que root faz parte do othersgrupo. Se você tentasse editar esse arquivo como root, veria que não teria problemas em fazer isso.
Mas para testar ainda mais sua teoria, se o arquivo pertencesse ao root:
-r--r-xrw-. 1 root root 8 Jan 29 18:40 test.file
E você foi editar o arquivo novamente, verá 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ê editou novamente o arquivo que veria (pelo menos no vi/vim) "test.file" [readonly]. Mas você ainda pode editar o arquivo e forçar o salvamento com a extensão :wq!.
Testando a afirmação de @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 apenas citar em vez de reafirmar:
Nota: A existência do bit de execução é verificada, não se é aplicável ao root.
Responder2
O Root tem acesso total a todos os arquivos do sistema por design. Se você deseja proteger um arquivo contra exclusão acidental, você pode usar
chattr +i file
Isso definirá o sinalizador imutável no GNU/Linux. Você pode removê-lo com -iem vez de +i.
No FreeBSD, você pode usar
chflags schg file
Substitua noschgpor schgpara desfazer.
Se você deseja proteger um arquivo contra a visibilidade do root, armazene-o em um sistema diferente ou use a criptografia como último recurso.
Responder3
Os direitos poderiam ser alterados para que o root tenha menos permissões que o proprietário?
Shure, é 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, é uma má ideia.
Você não é a primeira pessoa a fazer essa pergunta, e algumas dessas pessoas tiveram a ideia de capacidades, mas falaremos disso em breve, primeiro vamos começar entendendo como o sistema de permissão funciona.
Para iniciar, a parte do computador que faz as verificações de acesso não sabe o seu nome, ela conhece você pelo número, e esse número é chamado de uid ou identificador de usuário. de forma semelhante, ele não sabe os nomes dos grupos dos quais você faz parte, apenas o gid. o mapeamento entre uid e nome está no arquivo passwd e o gid está mapeado no arquivo groups.
Agora, quando você deseja abrir um arquivo, quatro verificações são feitas: você tem permissão para pular as verificações, você como usuário tem permissão para isso, você como membro de um grupo tem permissão para fazê-lo e como outra pessoa você tem permissão para isso? permitido. Estou pulando algumas coisas aqui, como troca de serviço de nomes e listas de controle de acesso e execução de leitura e 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 que? e (muito importante) Quando? Agora, há algumas coisas que às vezes precisam ser feitas e que você não quer que ninguém faça e que não se enquadram muito bem no modelo de permissão de arquivo. Todo tipo de coisa, como abrir uma conexão de rede em uma porta baixa, montar uma partição ou pular 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 a respeito, hoje em dia você pode dar recursos a outros usuários ou descartá-los, mas o padrão é o comportamento antigo.
A outra maneira de restringir o root é com algo como o selinux, mas isso é outra bola de cera.
Responder4
Quais os direitos de root neste caso? Tem 777?
Sim.
Como já foi dito, as permissões de leitura e gravação não são impostas ao 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 porque o grupo tem a xbandeira.
Observe também que, independentemente de a permissão de gravação ser concedida ou não, o root ou qualquer pessoa terá acesso de gravação recusado a um arquivo armazenado em um sistema de arquivos somente leitura.
O root também pode ter menos direitos que o proprietário se o arquivo estiver armazenado em um diretório montado remotamente como o NFS.
Finalmente, observe que as permissões de links simbólicos são essencialmente sem sentido.