sudo chmod o + x mas ainda não pode ser executado como usuário regular

Question

Eu pensei que fazer sudo chmod a+x /root/file.to.execute ou mesmo sudo chmod 777 /root/file.to.execute deveria permitir que eu, como usuário, executasse o programa em questão. Mas depois de fazer isso, ainda não consigo executá-lo como um usuário comum.

O que mais poderia estar dando errado? Todo tutorial que eu olho sobre chmod diz para fazer exatamente isso.

edit:

$ sudo ls -l /root/.cabal/bin/pandoc
-rwxrwxrwx 1 root root 37443252 Feb 23 14:56 /root/.cabal/bin/pandoc

edit: Apenas chamando /root/.cabal/bin/pandoc -v para remover outras fontes de erro: apenas a chamada mais simples para o programa.

    

Answer 1

Para executar um arquivo /path/to/file (e acessá-lo em geral), a conta do usuário deve ser capaz de acessá-lo primeiro, ou seja, para todos os pais de file , o usuário deve ter a permissão x .

No seu caso, você precisaria de chmod +x /root /root/.cabal /root/.cabal/bin , mas uma abordagem melhor provavelmente seria instalar pacotes de cabala localmente (para o usuário que precisa deles) ou globalmente se todos os usuários os tivessem. Por favor, consulte o manual da cabala para detalhes.

Veja também as perguntas relacionadas aqui e aqui para mais informações sobre o diretório permissões.

    

Answer 2

Podem ser todos os possíveis problemas.

Saber mais detalhes sobre o que o programa pode fazer pode ser útil. Por exemplo, um programa pode não ter permissão para gravar em um diretório em um sistema de arquivos que é montado como somente leitura, mesmo que os arquivos especifiquem que as permissões no estilo Unix permitiriam que o arquivo fosse sobrescrito (quando montado, leia / escrever).

Suas configurações de permissões no estilo Unix para o arquivo, que são definidas por chmod, parecem boas. Eu concordo com isso, com base na saída que você mostrou. Então, vamos tentar ver algumas outras coisas.

Algumas idéias rápidas: mount pode ter noexec (verifique o ponto de montagem / root se ele existir; meu palpite provavelmente não é, nesse caso você vai querer verificar o ponto / mount)

Permissões causadas por outra coisa. por exemplo, a primeira linha de um arquivo de script diz! # / bin / my-interpretor, mas você não tem permissões para executar o my-interpretor

Se você está recebendo um erro de permissão, talvez um arquivo execute my-interpretor, mas o arquivo executa outro programa que está causando erros.

A resposta de Frank registra o SELinux. Portanto, pode haver fontes de permissões diferentes daquelas que estão em um arquivo. Se o arquivo for um arquivo de script, tente obtê-lo. (Isto é: em vez de executar "/ path / file", execute ". / Path / file" - com um período e um espaço e depois um nome de arquivo. Ou o comando "source"; detalhes podem ser dependentes do shell. / p>

Talvez outro possível motivo possa estar relacionado a "ulimit -a"? (Isso pode ser um comando interno de um shell, então não apenas "man ulimit" - em vez disso, "man $ SHELL")

Talvez algumas dessas ideias estejam um pouco erradas, mas essas são apenas algumas das ideias que aparecem na minha cabeça. Então, eu não estou dizendo que todas essas respostas são possíveis, ou mesmo que todas essas são definitivamente possíveis; são apenas algumas ideias e talvez uma delas esteja certa.

Resolução de problemas: verifique os arquivos de registro. Verifique o valor de retorno (echo $?). E se o root executar o programa? E se uma pessoa usa "sudo"? E se uma pessoa do grupo "roda" executar o programa?