Perché la fonte di Bash non ha bisogno del bit di esecuzione?

Con Bash sourceè possibile eseguire uno script senza un set di bit di esecuzione. Questo è un comportamento documentato e atteso, ma non è contro l'uso di un bit di esecuzione?

Lo so, questo sourcenon crea una subshell.

Bash è un interprete; accetta input e fa quello che vuole. Non è necessario prestare attenzione al bit eseguibile. In effetti, Bash è portatile e può essere eseguito su sistemi operativi e filesystem che non hanno alcun concetto di bit eseguibile.

Ciò che interessa del bit eseguibile è il kernel del sistema operativo. Quando il kernel Linux esegue exec, ad esempio, controlla che il filesystem non sia montato con noexecun'opzione, controlla il bit eseguibile del file di programma e applica tutti i requisiti imposti dai moduli di sicurezza (come SELinux o AppArmor).

Si noti che il bit eseguibile è un tipo di controllo piuttosto discrezionale. Su un sistema Linux x86-64, ad esempio, è possibile ignorare la verifica del bit eseguibile da parte del kernel invocando esplicitamente /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2come interprete :

cp /bin/ls /tmp/
chmod -x /tmp/ls
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /tmp/ls

Questo è in qualche modo analogo all'acquisizione del codice sorgente di Bash in Bash, tranne che ld.soè l'interprete, e il codice che esegue è il codice macchina in formato ELF.

sourceo l'equivalente, ma di serie dot. non eseguire lo script, ma leggere i comandi dal file di script, per poi eseguire, riga per riga, in ambiente di shell corrente.

Non c'è niente contro l'uso di bit di esecuzione, perché il guscio solo bisogno leggere il permesso di leggere il contenuto dei file.

Il bit di esecuzione è richiesto solo quando si esegue lo script. Qui la shell eseguirà un fork()nuovo processo, quindi utilizzerà la execve()funzione per creare una nuova immagine di processo dallo script, che deve essere un normale file eseguibile.

Il bit eseguibile (a differenza del resto) sui file nonsetuid e nonsetguid non è molto un meccanismo di sicurezza. Qualunque cosa tu possa leggere, puoi eseguire indirettamente, e Linux ti consentirà di leggere indirettamente tutto ciò che puoi eseguire ma non leggere direttamente (ciò dovrebbe essere sufficiente per creare un buco nel concetto di non-set (g) uid x-bit essendo un misure di sicurezza).

È più una questione di convenienza: lascia che il sistema lo esegua direttamente per me se il bit è impostato, altrimenti devo farlo indirettamente ( bash the_script;o qualche hacking per ottenere l'immagine di memoria di un eseguibile senza permesso di lettura ).

Puoi impostarlo per comodità se intendi sia in-source che eseguire l'insourcable.

Apparentemente, tuttavia, molti implementatori di librerie condivise condividono il tuo pensiero e, di conseguenza, molti sistemi richiedono che le librerie condivise, che sono essenzialmente l'equivalente nativo degli insourcables della shell, siano contrassegnate come eseguibili per essere utilizzabili. Vedi Perché sono eseguibili le librerie condivise? .

Questa è una bella domanda! Unix utilizza il bit eseguibile per distinguere tra programmi e dati. Il sistema operativo non richiede il bit di esecuzione, poiché uno script di origine non viene passato al sistema operativo per l'esecuzione come nuovo processo. Ma la shell tratta uno script di provenienza come un programma e cercherà $PATHil file che si desidera ottenere. Quindi, la shell stessa avrebbe potuto richiedere l'autorizzazione di esecuzione per i file di origine; ma non lo fece.

La domanda deve essere stata posta molto tempo fa. Il design della shell Bourne è stato il risultato di "una lunga sequenza di modifiche, dialoghi, discussioni" tra gli abitanti di Bell Labs e molte decisioni di progettazione sono state discusse da SR Bourne e altri nel corso degli anni. Sfortunatamente, il mio rapido sguardo non ha trovato alcuna discussione sulla funzione di origine (a mia difesa, è difficile cercarlo su Google). Quello che ho trovato è che il "." Il comando non appare in questa prima introduzione alla shell dello stesso Bourne, ma è presente nella versione 7 più matura .

Assente autorità, ecco la mia interpretazione:

1. Il .comando, aka source, è in effetti inclusione testuale (come #includenel preprocessore C) nel codice sorgente dello script in esecuzione o della sessione interattiva. Pertanto, il file incluso non è probabilmente "eseguito".

2. La filosofia Unix è sempre stata quella di dare ai programmatori abbastanza corda per impiccarsi. Troppe restrizioni arbitrarie e di stretta di mano si frappongono. Solo di recente alcune distribuzioni hanno rm -r /rifiutato di fare ciò che chiedi. (Questo comando dice rmdi cancellare tutto sul tuo computer. Non provarlo come root! O meglio ancora, per niente.) Quindi, forse Bourne ad al. ho appena deciso che quando si tenta di creare un file, si presuppone che si sappia cosa si sta facendo. Ciò evita anche il lavoro non necessario e i cicli contavano molto allora.

Per quanto riguarda il sistema operativo, un file contenente script di shell sono solo dati. Se si passa il nome di tale file di dati al sourcecomando o lo si passa dalla riga di comando a un richiamo della shell bash, tutto il sistema operativo vede una stringa che coincide con il nome di un file contenente dati.

Come sarebbe il bit di esecuzione rilevante in quel caso?

La distinzione è importante perché potresti avere un file di comandi shell che non è utile come eseguibile, ma utile solo quando è di origine. Per questo file è possibile disattivare il bit di esecuzione e quindi non sarà mai possibile accedervi se non esplicitamente in un comando di origine. La ragione di una cosa del genere è avere effetti collaterali sulla shell da cui è stata lanciata. Per un esempio specifico, ho uno script chiamato fix_path che guarda e modifica il percorso.

Nel caso in cui qualcuno fosse interessato a ulteriori studi e / o chiarimenti: in una shell quasi conforme a POSIX implementata qualche tempo fa, i meccanismi interni delle funzioni 'exec_program ()' e 'builtin_source ()' sono molto esemplari. In quelle funzioni vedi esattamente qual è la differenza tra loro:

https://github.com/rsenn/shish/blob/master/src/builtin/builtin_source.c

https://github.com/rsenn/shish/blob/master/src/exec/exec_program.c

sostanzialmente il sourcing può essere visto come la shell che reindirizza temporaneamente il suo descrittore di file interno da dove analizza lo script della shell (il terminale in modalità interattiva). quindi è molto simile ad altri reindirizzamenti come <input_file.txte >>append_to_something.liste questi devono solo aprire e chiudere i file.

pertanto l'esecuzione è gestita dalla execve()chiamata di sistema per cui il bit di esecuzione è obbligatorio.

Ricordo di aver visto alcuni sistemi che consentono l'esecuzione di file binari ELF / a.out, ma tramite l'esecuzione di "/lib/ld-dynamic-linker.so" e con il programma binario (senza bit di esecuzione) come primo argomento. Credo che fosse su alcune macchine DEC Alpha o VAX (avrebbe potuto essere SCO Unix?)

Un altro punto di vista:

Lo script di origine è essenzialmente composto da shell incorporate e chiamate di programma. I builtin della shell ( sourcetra cui) sono parti della shell e la shell deve essere eseguibile in primo luogo. Ogni programma chiamato (che sia ELF, un altro script con shebang, qualunque cosa) deve avere un bit di esecuzione impostato, altrimenti non verrà eseguito.

Quindi non è contro l'uso di un bit di esecuzione, perché non verrà eseguito nulla senza bit di esecuzione. La convalida non si verifica per l'intero script di provenienza; viene eseguito per ogni parte separatamente, ma lo è.