Execute ./script.sh vs bash script.sh - permissão negada

Question

Quando tento executar ./script.sh , recebo Permission denied , mas quando executo bash script.sh , tudo está bem.

O que eu fiz de errado?

    

Answer 1

Permissões POSIX incorretas

Isso significa que você não tem o bit de permissão de execução definido para script.sh . Ao executar bash script.sh , você só precisa de permissão de leitura para script.sh . Consulte O que é a diferença entre executar “bash script.sh” e “./script.sh”? para mais informações.

Você pode verificar isso executando ls -l script.sh .

Você pode nem precisar iniciar um novo processo de Bash. Em muitos casos, você pode simplesmente executar source script.sh ou . script.sh para executar os comandos de script no seu shell interativo atual. Você provavelmente desejaria iniciar um novo processo de Bash se o script alterasse o diretório atual ou modificasse o ambiente do processo atual.

Listas de controle de acesso

Se os bits de permissão POSIX estiverem definidos corretamente, a Lista de Controle de Acesso (ACL) pode ter sido configurada para impedir que você ou seu grupo executem o arquivo. Por exemplo. as permissões POSIX indicariam que o script de shell de teste é executável.

$ ls -l t.sh
-rwxrwxrwx+ 1 root root 22 May 14 15:30 t.sh

No entanto, a tentativa de executar o arquivo resulta em:

$ ./t.sh
bash: ./t.sh: Permission denied

O comando getfacl mostra o motivo:

$ getfacl t.sh
# file: t.sh
# owner: root
# group: root
user::rwx
group::r--
group:domain0users:rw-
mask::rwx
other::rwx

Nesse caso, meu grupo principal é domain users , que teve as permissões de execução revogadas, restringindo a ACL com sudo setfacl -m 'g:domain0users:rw-' t.sh . Essa restrição pode ser levantada por um dos seguintes comandos:

sudo setfacl -m 'g:domain0users:rwx' t.sh
sudo setfacl -b t.sh

Veja:

• Listas de controle de acesso, Arch Linux Wiki
• Usando ACLs com o Fedora Core 2

Sistema de arquivos montado com opção noexec

Por fim, o motivo para não poder executar o script neste caso é que o sistema de arquivos no qual o script reside foi montado com a opção noexec . Esta opção substitui as permissões POSIX para impedir que qualquer arquivo nesse sistema de arquivos seja executado.

Isto pode ser verificado executando mount para listar todos os sistemas de arquivos montados; as opções de montagem são listadas entre parênteses na entrada correspondente ao sistema de arquivos, por exemplo,

/dev/sda3 on /tmp type ext3 (rw,noexec)

Você pode mover o script para outro sistema de arquivos montado ou remontar o sistema de arquivos, permitindo a execução:

sudo mount -o remount,exec /dev/sda3 /tmp

Observação: usei /tmp como exemplo, pois há bom razões de segurança para manter /tmp montado com o conjunto de opções noexec,nodev,nosuid .

    

Answer 2

Tente

chmod 755 script.sh

isso tornará o arquivo executável. Então tente,

./script.sh

Espero que isso funcione.

    

Answer 3

No meu win7 com o admin executando cmd; Eu tenho arquivos .sh associados com cygwin64 / bin / bash, mas foi bloqueado por cmd. Nenhuma das sugestões acima ajudou (chmod, setfacl, mount).

A solução abaixo funcionou, é um acl-fixer do administrador sempre que as pastas / arquivos ficam inacessíveis ao admin no win7, que é frequentemente):

  Start > run cmd as Admin
  c:\> script.sh
    Access is denied.

  cmd> chmod 0777 script.sh c:\cygwin64\bin\bash.exe
  cmd> script.sh
    Access is denied.

  > assoc .sh
  .sh=bash

  > ftype bash
  bash=C:\cygwin64\bin\bash.exe -- "%1" %*

  > bash
  $ FILE=c:/cygwin64/bin/bash.exe
  $ FILE=${FILE////\} # s,/,\,g

  # Compare these permissions using accesschk by Mark Russinovich 2015
  $ accesschk.exe -lq  $FILE 
  $ accesschk.exe -lq c:/windows/system32/cmd.exe
  # [large output not shown]

  # === Solution: Change windows acl for bash ===
  $ takeown /F $FILE /A > /dev/null
  $ icacls $FILE /t /q /c /reset
  $ icacls $FILE /t /q /c /grant    :r Everyone:F
  $ icacls $FILE /t /q /c /setowner Administrators  
  # ====

  cmd> script.sh
    OK .. invokes bash