Esecuzione di script sh: «Autorizzazione negata» nonostante il bit eseguibile e i diritti di root

17

Ho installato Debian in VirtualBox (per vari esperimenti che di solito hanno rotto il mio sistema) e ho provato ad avviare lo script del componente aggiuntivo guest VirtualBox. Ho effettuato l'accesso come root e ho tentato di avviarlo autorun.sh, ma ho ottenuto "Autorizzazione negata". ls -lmostra che lo script ha diritti eseguibili.

Siamo spiacenti, non riesco a copiare l'output: VirtualBox non ha assolutamente alcun uso senza l'addon, poiché non funziona né una directory condivisa, né un blocco appunti condiviso. Ma solo per essere sicuro, ho copiato i diritti a mano:

#ls -l ./autorun.sh
-r-xr-xr-x 1 root root 6966 Mar 26 13:56 ./autorun.sh

All'inizio ho pensato che potrebbe essere che lo script esegua qualcosa che ha dato l'errore. Ho provato a sostituirlo /bin/shcon qualcosa del genere #/pathtorealsh/sh -xv, ma non ho ottenuto alcun output: sembra che lo script non possa nemmeno essere eseguito.

Non ho nemmeno idea di cosa potrebbe causarlo.

— Ciao Angelo
fonte

2

Sembra che dovrebbe funzionare. Prova a eseguirlo esplicitamente con bash: `bash -x ./autorun.sh". Forse questo darà un ulteriore indizio.

— nobar

2

Da cosa viene prodotto mount | grep noexec?

— cuonglm,

1

@Gnouc, hai ragione, i «cdrom» montati hanno il noexecset. Probabilmente puoi pubblicarlo come risposta; nel frattempo sto cercando di rimontarlo con i diritti di un dirigente. Hm, non sapevo nemmeno che il filesystem potesse avere un tale attributo.

— Ciao Angelo

E se provi a eseguirlo andando andando sh ./autorun.shcosa succede?

— apposto il

29

Forse il tuo file system è montato con noexecset di opzioni, quindi non puoi eseguire file eseguibili. Dalla documentazione di mount :

noexec

Non consentire l'esecuzione diretta di alcun file binario sul filesystem montato. (Fino a poco tempo fa era possibile eseguire comunque i binari usando un comando come /lib/ld*.so / mnt / binary. Questo trucco fallisce da Linux 2.4.25 / 2.6.0.)

Provare:

mount | grep noexec

Quindi controlla se il tuo file system è elencato nell'output.

In caso affermativo, è possibile risolvere questo problema, reinstallando il file system con l' execopzione:

mount -o remount,exec filesystem

— cuonglm
fonte

Non ha funzionato per me. Ho dovuto smontare e rimontare normalmente. Quindi ha funzionato bene.

— datakid,

@datakid: qual è il tuo fs?

— cuonglm,

Sto riscontrando questo problema con debian 9, alcuni file non sono autorizzati se gli script funzionano come root, ma si identificano come root ... come un comportamento di Windows, se rimuovo e lo script ha funzionato! = [

— Luciano Andress Martini,

Stavo ricevendo un messaggio molto strano, che si è rivelato essere dovuto a noexec: "sh: 75: script.sh: autorizzazione negata"

— tmm1

2

bash -x ./filename.filetypedovrebbe funzionare. Ha funzionato per me quando mi è stato negato il permesso come utente root.

— Stephen Howe
fonte

No, poiché alla fine il problema si è rivelato essere l' noexecopzione di montaggio, questo non funzionerà, perché potrebbero esserci più file da eseguire; vale a dire filename.filetypeansimerebbe cercando di eseguire altri file dallo stesso filesystem. Puoi facilmente verificarlo con un test semplificato: crea uno script a due righe che stampa "ciao", quindi si chiama di nuovo, ma non imposta diritti eseguibili. Se lo esegui con -x, stampa "ciao", ma la linea di chiamata ricorsiva genererebbe un errore.

— Ciao Angelo

1

La mia soluzione a questo problema è utilizzare l' origine . Ero su un volume di archiviazione di dati molto importanti. Questo volume è montato come noexec. Ho un semplice script shell che è eseguibile ma ho avuto problemi di autorizzazione.

./fixsamplesheet.sh # this guy is executable
-bash: ./fixsamplesheet.sh: Permission denied

source fixsamplesheet.sh # worked fine

Testato solo sul mio Ubuntu.

— Kemin Zhou
fonte