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

Quando tento correr ./script.sh, consegui, Permission deniedmas quando corro bash script.shestá tudo bem.

O que eu fiz errado?

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 Qual é 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 do Bash. Em muitos casos, você pode simplesmente executar source script.shou . script.shexecutar os comandos de script no seu shell interativo atual. Você provavelmente desejaria iniciar um novo processo Bash se o script alterar o diretório atual ou modificar 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 execute o arquivo. Por exemplo, as permissões POSIX indicariam que o script do 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 getfaclcomando mostra o motivo pelo qual:

$ getfacl t.sh
# file: t.sh
# owner: root
# group: root
user::rwx
group::r--
group:domain\040users:rw-
mask::rwx
other::rwx

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

sudo setfacl -m 'g:domain\040users:rwx' t.sh
sudo setfacl -b t.sh

Vejo:

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

Sistema de arquivos montado com a opção noexec

Finalmente, a razão, neste caso específico, de não conseguir executar o script, é que o sistema de arquivos em que o script reside foi montado com a noexecopção Esta opção substitui as permissões POSIX para impedir que qualquer arquivo desse sistema de arquivos seja executado.

Isso pode ser verificado executando-se mountpara listar todos os sistemas de arquivos montados; as opções de montagem estã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

Nota: usei /tmpcomo exemplo aqui, pois existem boas razões de segurança para manter-se /tmpmontado com o noexec,nodev,nosuidconjunto de opções.

Experimentar

chmod 755 script.sh

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

./script.sh

Espero que isso funcione.

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

A solução abaixo funcionou: é um acl-fixer admin sempre que pastas / arquivos ficam inacessíveis para admin no win7, o que geralmente é):

  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