Come posso forzare in modo esplicito e sicuro l'uso di un comando integrato in bash

C'è una domanda simile che si occupa dello scenario "wrapping", in cui si desidera sostituire, ad esempio, cdun comando che chiama l'integrato cd.

Tuttavia, alla luce di shellshock et al e sapendo che bash importa le funzioni dall'ambiente, ho fatto alcuni test e non riesco a trovare un modo per chiamare in modo sicuro l'integrato cddal mio script.

Considera questo

cd() { echo "muahaha"; }
export -f cd

Qualsiasi script chiamato in questo ambiente utilizzando cdsi interromperà (considerare gli effetti di qualcosa di simile cd dir && rm -rf .).

Ci sono comandi per controllare il tipo di comando (chiamato convenientemente type) e comandi per eseguire la versione integrata piuttosto che una funzione ( builtine command). Ma ecco, questi possono essere ignorati anche usando le funzioni

builtin() { "$@"; }
command() { "$@"; }
type() { echo "$1 is a shell builtin"; }

Produrrà quanto segue:

$ type cd
cd is a shell builtin
$ cd x
muahaha
$ builtin cd x
muahaha
$ command cd x
muahaha

Esiste un modo per forzare in modo sicuro bash a utilizzare il comando incorporato o almeno rilevare che un comando non è un comando incorporato, senza cancellare l'intero ambiente?

Mi rendo conto che se qualcuno controlla il tuo ambiente probabilmente sei fregato comunque, ma almeno per gli alias hai la possibilità di non chiamare l'alias inserendo un \prima.

Olivier D è quasi corretto, ma è necessario impostare POSIXLY_CORRECT=1prima di correre unset. POSIX ha una nozione di incorporamenti speciali e bash lo supporta . unsetè uno di questi builtin. Cerca SPECIAL_BUILTINin builtins/*.cnella fonte bash per una lista, che include set, unset, export, evale source.

$ unset() { echo muahaha-unset; }
$ unset unset
muahaha-unset
$ POSIXLY_CORRECT=1
$ unset unset

Il ladro unsetè stato rimosso dall'ambiente, Se viene disattivata command, type, builtinallora si dovrebbe essere in grado di procedere, ma unset POSIXLY_CORRECTse si fa affidamento sulla non-POSIX comportamento o funzionalità bash avanzate.

Tuttavia, questo non risolve gli alias, quindi è necessario \unsetassicurarsi che funzioni nella shell interattiva (o sempre, nel caso in cui expand_aliasessia attivo).

Per il paranoico, questo dovrebbe sistemare tutto, penso:

POSIXLY_CORRECT=1
\unset -f help read unset
\unset POSIXLY_CORRECT
re='^([a-z:.\[]+):' # =~ is troublesome to escape
while \read cmd; do 
    [[ "$cmd" =~ $re ]] && \unset -f ${BASH_REMATCH[1]}; 
done < <( \help -s "*" )

( while, do, doneE [[sono parole riservate e non hanno bisogno precauzioni.) Si noti che stiamo usando unset -fper essere sicuri di funzioni impostata, anche se le variabili e le funzioni condividono lo stesso spazio dei nomi è possibile per entrambi di esistere contemporaneamente (grazie a Etan Reisner), nel qual caso anche il disinserimento due volte farebbe il trucco. È possibile contrassegnare una funzione di sola lettura, bash non impedisce che si disinserimento una funzione di sola lettura fino al bash-4.2, bash-4.3 osta a voi, ma onora ancora i comandi incorporati speciali quando POSIXLY_CORRECTè impostato.

Un readonly POSIXLY_CORRECTnon è un vero problema, questo non è un valore booleano o contrassegna la sua presenza abilita la modalità POSIX, quindi se esiste come readonly puoi fare affidamento sulle funzionalità POSIX, anche se il valore è vuoto o 0. Devi semplicemente disinserire le funzioni problematiche in un modo diverso rispetto a quello sopra, forse con alcune funzioni taglia e incolla:

\help -s "*" | while IFS=": " read cmd junk; do echo \\unset -f $cmd; done

(e ignorare eventuali errori) o impegnarsi in alcuni altri script .

Altre note:

• functionè una parola riservata, può essere aliasata ma non sovrascritta con una funzione. (L'aliasing functionè leggermente fastidioso perché \function non è accettabile come modo per aggirarlo)
• [[, ]]sono parole riservate, possono essere aliasate (che verranno ignorate) ma non sovrascritte da una funzione (sebbene le funzioni possano essere chiamate così)
• (( non è un nome valido per una funzione, né un alias

Mi rendo conto che se qualcuno controlla il tuo ambiente probabilmente sei fregato comunque

Sì, quello. Se si esegue uno script in un ambiente sconosciuto, tutto può andare storto, a partire LD_PRELOADdal processo di shell per eseguire codice arbitrario prima ancora di leggere lo script. Tentare di proteggere un ambiente ostile dall'interno della sceneggiatura è inutile.

Sudo ha igienizzato l'ambiente rimuovendo tutto ciò che sembra una definizione della funzione bash da oltre un decennio. Da Shellshock , altri ambienti che eseguono script di shell in un ambiente non completamente affidabile hanno seguito l'esempio.

Non è possibile eseguire in modo sicuro uno script in un ambiente impostato da un'entità non attendibile. Quindi preoccuparsi delle definizioni delle funzioni non è produttivo. Disinfetta il tuo ambiente e nel fare ciò variabili che bash interpreterebbero come definizioni di funzione.

È possibile utilizzare unset -fper rimuovere le funzioni integrate, comando e tipo.