Por que não é possível executar root quando os bits executáveis não estão definidos?

26

root user pode gravar em um arquivo, mesmo que suas permissões write não estejam definidas.

root user pode ler um arquivo, mesmo que suas permissões read não estejam definidas.

root user pode cd em um diretório, mesmo que suas permissões execute não estejam definidas.

root user não pode executar um arquivo quando suas permissões execute não estão definidas.

Por quê?

user$ echo '#!'$(which bash) > file
user$ chmod 000 file
user$ ls -l file
---------- 1 user user 12 Jul 17 11:11 file
user$ cat file                      # Normal user cannot read
cat: file: Permission denied
user$ su
root$ echo 'echo hello' >> file     # root can write
root$ cat file                      # root can read
#!/bin/bash
echo hello
root$ ./file                        # root cannot execute
bash: ./file: Permission denied
    
por musa 17.07.2012 / 11:17

2 respostas

25

Em suma, porque o bit de execução é considerado especial; se não for definido , , o arquivo será considerado não executável e, portanto, não poderá ser executado.

No entanto, se até um dos bits de execução estiver definido, o root poderá executá-lo.

Observe:

caleburn: ~/ >cat hello.sh
#!/bin/sh

echo "Hello!"

caleburn: ~/ >chmod 000 hello.sh
caleburn: ~/ >./hello.sh
-bash: ./hello.sh: Permission denied
caleburn: ~/ >sudo ./hello.sh 
sudo: ./hello.sh: command not found

caleburn: ~/ >chmod 100 hello.sh
caleburn: ~/ >./hello.sh
/bin/sh: ./hello.sh: Permission denied
caleburn: ~/ >sudo ./hello.sh 
Hello!
    
por 17.07.2012 / 11:45
0

Antigamente, as ferramentas de administração do sistema viviam em /etc , como /etc/restore , /etc/rrestore , /etc/init , /etc/halt , etc. Imagine o que aconteceria se root ' PATH fosse definido para /etc:/bin e root ran passwd .

Não funcionaria direito.

Para piorar, antigamente, os executáveis binários não tinham cabeçalhos mágicos, então verificar se o binário era um executável não era realmente possível, exceto verificando os bits de permissão. Assim, eles criaram arquivos que não eram destinos válidos de exec *, a menos que fossem realmente arquivos (sem diretórios, etc.) e tivessem pelo menos um conjunto de bits de execução.

* A verificação pode ter sido em execvp, que é uma função do modo de usuário.

Ainda é uma verificação útil, pois, em teoria, qualquer coisa poderia ser um shell script, então, por que remover isso?

    
por 29.04.2017 / 03:17