Por que preciso de um bit 'execute' no modo de arquivo em sistemas de arquivos Unix?

Question

Quando recebo um arquivo executável com permissão somente leitura (leitura e execução para raiz), sempre posso copiá-lo para meu diretório pessoal onde tenho permissão de controle total. Então eu defino o novo arquivo para ler e executar. Ok, eu posso executá-lo.

É realmente necessário para um modo de arquivo? Eu sei que para diretórios isso significa diferente.

    

Answer 1

Estou surpreso que ninguém tenha mencionado binários que são executados com privilégios especiais. O Wireshark vem com um caso de uso do mundo real aqui: uma de suas principais funções é capturar o tráfego de rede, algo que normalmente apenas o root pode fazer. Faz sentido que você queira permitir que certos usuários capturem o tráfego com o Wireshark sem precisar acessá-los totalmente, então o Wireshark vem com um binário chamado dumpcap que possui os recursos necessários (CAP_NET_RAW e CAP_NET_ADMIN) ativados. Esse binário é 0754 ( rwxr-xr-- ) e seu GID associado é um grupo especial que o Wireshark instala. Dessa forma, qualquer usuário do grupo pode executar o binário (geralmente através do Wireshark) para capturar o tráfego, e ele será executado com os privilégios necessários para fazê-lo, mas um usuário que não estiver nesse grupo não poderá, porque não faria isso. t tem permissão de execução. Eles ainda poderiam copiá-lo para seu diretório pessoal, mas a cópia não teria os recursos necessários definidos, por isso não poderia realmente capturar nenhum tráfego.

    

Answer 2

Porque o * nix não é danificado o suficiente para criar um arquivo "executável binário", caso você o chame de ".exe" ou "executável de script", caso o nomeie ".bat".

No Linux, o nome do arquivo não importa.

E as permissões que você dá a um arquivo do são importantes.

Que tipo de sentido faz sentido. IMHO ...

    

Answer 3

O bit de execução é um pouco confuso entre ser uma permissão e um identificador de tipo de objeto.

E não, você não pode "copiar sempre" o arquivo para seu diretório pessoal: somente se ele for legível para você.

Os arquivos podem ser executáveis para você, mas não podem ser lidos.

Você tem razão em que, se um arquivo puder ser lido para você, mas não puder ser executado por você, você poderá copiá-lo, inverter o bit de execução e usá-lo. Talvez. Mas pode não funcionar. O executável pode ser sensível para onde está instalado. Ou o arquivo pode depender do seu bit raiz setuid.

Eu não criaria um sistema de permissão assim começando de uma lousa limpa; isso não faz totalmente sentido. A permissão para executar seria separada de um atributo de tipo executável, e a permissão de execução não seria sobrecarregada com permissão de pesquisa (mesmo se fosse armazenada dessa maneira; a API não a revelaria no nível da máscara de bits).

    

Answer 4

Esse é um bom ponto, e eu acho que vejo onde você está indo com isso.

Para reinterpretar sua pergunta: A afirmação a seguir é verdadeira - "Definir um executável como modo não executável para um usuário não limita as capacidades do usuário".

Eu acho que é verdade.

1. Copie o arquivo para outro diretório.
2. Alterar permissões de execução.
3. Execute a partir de qualquer pwd (em particular, o diretório original), dando caminho completo para a nova cópia do executável, com quaisquer argumentos de linha de comando.

Eu não acho que haja mais nada faltando, o que você teria com o conjunto de exec do arquivo original.

Por pwd quero dizer presente diretório de trabalho.

    

Answer 5

Existem muitos motivos pelos quais você pode querer marcar um arquivo como legível, mas não executável, especialmente por determinados usuários ou grupos. Considere o seguinte:

# /usr/local/sbin/foo.sh
-rwxr--r-- 1 root root 890 2012-02-17 21:09 /usr/local/sbin/foo.sh

# ~/bin/foo.sh
-rwxr-xr-x 1 user user 890 2012-02-17 21:09 /home/bin/foo.sh

Isso pode fazer sentido se:

1. Os arquivos são diferentes - talvez você tenha substituído todas as instâncias de "root" por "user" no script - mas seu caminho contém /usr/local/sbin:/home/user/bin . As permissões garantirão que a execução de foo.sh execute a cópia modificada do usuário, mesmo que a cópia do root venha primeiro no caminho de pesquisa, se o bit de execução estiver definido.
2. Os arquivos são idênticos, mas fazem algo diferente em tempo de execução com base em seu nome de base, diretório pai, diretório pessoal do usuário chamador ou algum outro truque de programação inteligente. Nesses casos, você deseja que os usuários copiem o arquivo em outro lugar antes de executá-lo. Muitos scripts de exemplo removem o bit de execução para forçar os usuários a copiar e personalizar.

Em última análise, nada impede que você copie qualquer arquivo que possa ler ou até mesmo execute-o diretamente com sh /path/to/file . O bit de execução ausente do seu usuário ou grupo apenas o impede de fazer isso por acidente . Não é uma medida de segurança e não deve ser tomada por uma.

    

Answer 6

Pelo que entendi, você quer saber por que um arquivo somente de leitura não executável pode ser copiado para o seu diretório pessoal, onde é possível executá-lo e executá-lo, criando a ilusão de que o bit "executável" é desnecessário.

No seu caso, pode ser útil porque o executável pode funcionar apenas em seu local original, portanto, copiá-lo para um novo local e executá-lo falhará.

Por outro lado, ter seu próprio diretório pessoal com acesso total já lhe concede algum nível de confiança ao sistema. Existem muitas situações em que os usuários só têm acesso de leitura, caso em que você pode ler o arquivo executável, mas não pode executá-lo de qualquer maneira