Uruchom ./script.sh vs bash script.sh - odmowa uprawnień

Kiedy próbuję biec ./script.sh, mam, Permission deniedale kiedy biegam, bash script.shwszystko jest w porządku.

Co zrobiłem źle?

Niepoprawne uprawnienia POSIX

Oznacza to, że nie masz ustawionego bitu uprawnień do wykonywania script.sh. Podczas działania bash script.shpotrzebujesz tylko uprawnienia do odczytu dla script.sh. Zobacz Jaka jest różnica między uruchomieniem „bash script.sh” i „./script.sh”? po więcej informacji.

Możesz to sprawdzić, uruchamiając ls -l script.sh.

Być może nawet nie będziesz musiał rozpocząć nowego procesu Bash. W wielu przypadkach możesz po prostu uruchomić source script.shlub . script.shuruchomić polecenia skryptowe w bieżącej interaktywnej powłoce. Prawdopodobnie będziesz chciał rozpocząć nowy proces Bash, jeśli skrypt zmieni bieżący katalog lub w inny sposób zmodyfikuje środowisko bieżącego procesu.

Listy kontroli dostępu

Jeśli bity uprawnień POSIX są ustawione poprawnie, być może lista kontroli dostępu (ACL) została skonfigurowana tak, aby uniemożliwić tobie lub twojej grupie wykonanie pliku. Np. Uprawnienia POSIX wskazują, że skrypt powłoki testowej jest wykonywalny.

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

Jednak próba wykonania pliku powoduje:

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

getfaclKomenda pokazuje przyczynę:

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

W tym przypadku moją podstawową grupą jest ta, domain usersktóra ma uprawnienia do wykonania odwołane przez ograniczenie listy ACL za pomocą sudo setfacl -m 'g:domain\040users:rw-' t.sh. To ograniczenie można znieść za pomocą jednego z następujących poleceń:

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

Widzieć:

• Listy kontroli dostępu, Arch Linux Wiki
• Używanie list ACL w Fedorze Core 2

System plików zamontowany z opcją noexec

Wreszcie, w tym konkretnym przypadku niemożność uruchomienia skryptu polega na tym, że system plików, w którym znajduje się skrypt, został podłączony z noexecopcją. Ta opcja zastępuje uprawnienia POSIX, aby uniemożliwić wykonanie dowolnego pliku w tym systemie plików.

Można to sprawdzić, uruchamiając, mountaby wyświetlić listę wszystkich zamontowanych systemów plików; opcje montowania są wymienione w nawiasach we wpisie odpowiadającym systemowi plików, np

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

Możesz przenieść skrypt do innego zamontowanego systemu plików lub ponownie zamontować system plików, umożliwiając wykonanie:

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

Uwaga: Użyłem /tmptutaj jako przykładu, ponieważ istnieją dobre powody bezpieczeństwa, aby trzymać /tmpzamontowane z noexec,nodev,nosuidzestawem opcji.

Próbować

chmod 755 script.sh

dzięki temu plik będzie wykonywalny. Więc spróbuj,

./script.sh

Mam nadzieję, że to zadziała.

Na mojej win7 z adminem uruchomionym cmd; Mam pliki .sh związane z cygwin64 / bin / bash, ale zostało to zablokowane przez cmd. Żadna z powyższych sugestii nie pomogła (chmod, setfacl, mount).

Poniższe rozwiązanie zadziałało, jest to narzędzie administratora acl-fixer, gdy foldery / pliki stają się niedostępne dla administratora na win7, co często:

  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