Esegui ./script.sh vs bash script.sh - autorizzazione negata

Quando provo a correre ./script.shho capito Permission deniedma quando corro bash script.shtutto va bene.

Cosa ho fatto di sbagliato?

— Piotr Stapp
fonte

Puoi modificare la domanda in modo da includere il contenuto della riga shebang e anche l'output di getfacl script.sh?

— Anthony G - giustizia per Monica

Risposte:

Autorizzazioni POSIX errate

Significa che non hai impostato il bit di autorizzazione di esecuzione script.sh. Durante l'esecuzione bash script.sh, è necessaria solo l'autorizzazione di lettura per script.sh. Vedi Qual è la differenza tra l'esecuzione di "bash script.sh" e "./script.sh"? per maggiori informazioni.

Puoi verificarlo eseguendo ls -l script.sh.

Potrebbe non essere nemmeno necessario avviare un nuovo processo Bash. In molti casi, è possibile semplicemente eseguire source script.sho . script.sheseguire i comandi di script nella shell interattiva corrente. Probabilmente vorrai avviare un nuovo processo Bash se lo script cambia la directory corrente o modifica in altro modo l'ambiente del processo corrente.

Elenchi di controllo degli accessi

Se i bit di autorizzazione POSIX sono impostati correttamente, l'elenco di controllo di accesso (ACL) potrebbe essere stato configurato per impedire a te o al tuo gruppo di eseguire il file. Ad esempio, le autorizzazioni POSIX indicano che lo script della shell di test è eseguibile.

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

Tuttavia, il tentativo di eseguire il file comporta:

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

Il getfaclcomando mostra il motivo per cui:

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

In questo caso, il mio gruppo principale è domain usersche ha revocato le autorizzazioni di esecuzione limitando l'ACL con sudo setfacl -m 'g:domain\040users:rw-' t.sh. Questa limitazione può essere revocata da uno dei seguenti comandi:

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

Vedere:

File system montato con opzione noexec

Infine, il motivo in questo caso specifico per non essere in grado di eseguire lo script è che il filesystem su cui risiede lo script è stato montato con l' noexecopzione. Questa opzione sovrascrive le autorizzazioni POSIX per impedire l'esecuzione di qualsiasi file su quel file system.

Questo può essere verificato eseguendo mountper elencare tutti i filesystem montati; le opzioni di mount sono elencate tra parentesi nella voce corrispondente al filesystem, ad es

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

Puoi spostare lo script in un altro filesystem montato o rimontare il filesystem per consentire l'esecuzione:

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

Nota: ho usato /tmpcome esempio qui poiché ci sono buoni motivi di sicurezza per rimanere /tmpmontati con il noexec,nodev,nosuidset di opzioni.

— Anthony G - giustizia per Monica
fonte

Ho impostato chmod 777 e ho ancora questo errore.

— Piotr Stapp,

Non avevo un dirigente sulla partizione.

— Piotr Stapp,

quindi ho dannatamente nessun dirigente acceso e non è elencato in fstab. perché diavolo sta facendo questo alle mie partizioni non-tmp che ho?

— Deryck,

Era quell'opzione noexec in / etc / fstab.

— user208145

Vorrei aggiungere che è anche saggio verificare se la cartella contenente lo script è "eseguibile" o meno (quindi ha il flag X o meno). In caso contrario, lo script sarà eseguibile solo dall'utente root.

— Letokteren,

Provare

chmod 755 script.sh

questo renderà il file eseguibile. Quindi prova,

./script.sh

Spero che questo funzioni.

— ranga.sl
fonte

Iwelcomme to U&L, riformattato secondo la convenzione, tuttavia questo non aggiunge quasi nulla alla risposta precedente.

— Archemar,

a volte, la risposta più breve è la migliore :)

— Sameera Kumarasingha

Sul mio win7 con admin in esecuzione cmd; Ho file .sh associati a cygwin64 / bin / bash, ma è stato bloccato da cmd. Nessuno dei suggerimenti di cui sopra ha aiutato (chmod, setfacl, mount).

La soluzione di seguito ha funzionato, è un acl-fixer per amministratori di mazze ogni volta che cartelle / file diventano inaccessibili all'amministratore su win7, che è spesso):

  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

— mosh
fonte