¿Cómo forzo explícita y segura el uso de un comando incorporado en bash

Hay una pregunta similar que trata con el escenario de 'envoltura', donde desea reemplazar, por ejemplo, cdcon un comando que llama al incorporado cd.

Sin embargo, a la luz de shellshock et al y sabiendo que bash importa funciones del entorno, he realizado algunas pruebas y no puedo encontrar una manera segura de llamar al builtin cddesde mi script.

Considera esto

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

Cualquier script llamado en este entorno usando cdse romperá (considere los efectos de algo así cd dir && rm -rf .).

Hay comandos para verificar el tipo de comando (convenientemente llamado type) y comandos para ejecutar la versión incorporada en lugar de una función ( builtiny command). Pero, he aquí, estos pueden ser anulados usando funciones también

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

Producirá lo siguiente:

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

¿Hay alguna manera de forzar a bash de manera segura a usar el comando incorporado, o al menos detectar que un comando no es un incorporado, sin borrar todo el entorno?

Me doy cuenta de que si alguien controla su entorno, probablemente esté jodido de todos modos, pero al menos para los alias tiene la opción de no llamar al alias insertando un \antes.

Olivier D es casi correcto, pero debe configurarlo POSIXLY_CORRECT=1antes de ejecutarlo unset. POSIX tiene una noción de Special Built-ins , y bash lo admite . unsetes uno de esos incorporados. Buscar SPECIAL_BUILTINen builtins/*.cla fuente de fiesta para una lista, que incluye set, unset, export, evaly source.

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

El pícaro unsetahora ha sido retirado del medio ambiente, si de borra command, type, builtinentonces usted debería ser capaz de proceder, pero unset POSIXLY_CORRECTsi usted está confiando en un comportamiento no POSIX o características de bash avanzadas.

Sin embargo, esto no aborda los alias, por lo que debe usar \unsetpara asegurarse de que funciona en un shell interactivo (o siempre, en caso de que expand_aliasesesté vigente).

Para los paranoicos, esto debería arreglarlo todo, creo:

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, doneY [[son palabras reservadas y no necesitan precauciones.) Tenga en cuenta que estamos utilizando unset -fpara asegurarse de que las funciones no definidas, aunque variables y funciones comparten el mismo espacio de nombres que es posible tanto para existir simultáneamente (gracias a Etan Reisner), en cuyo caso Inmovilizar dos veces también haría el truco. Usted puede marcar una función de sólo lectura, golpe del no impide que desarmar una función de sólo lectura hasta e incluyendo bash-4.2, bash-4.3 le impide pero todavía rinde homenaje a las órdenes internas especiales cuando POSIXLY_CORRECTse establece.

Un solo lectura POSIXLY_CORRECTno es un problema real, no es un booleano o marca su presencia habilita el modo POSIX, por lo que si existe como solo lectura puede confiar en las características POSIX, incluso si el valor está vacío o 0. Simplemente necesitará desarma las funciones problemáticas de una manera diferente a la anterior, quizás con algo de cortar y pegar:

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

(e ignorar cualquier error) o participar en otros scriptobatics .

Otras notas:

• functiones una palabra reservada, puede ser alias pero no anulada con una función. (El alias functiones levemente problemático porque \function no es aceptable como una forma de evitarlo)
• [[, ]]son palabras reservadas, pueden tener un alias (que será ignorado) pero no anularse con una función (aunque las funciones pueden llamarse así)
• (( no es un nombre válido para una función, ni un alias

Me doy cuenta de que si alguien controla tu entorno, probablemente estés jodido de todos modos

Si, eso. Si ejecuta un script en un entorno desconocido, todo tipo de cosas pueden salir mal, comenzando por LD_PRELOADhacer que el proceso de shell ejecute código arbitrario antes de que incluso lea su script. Intentar protegerse contra un entorno hostil desde el interior del script es inútil.

Sudo ha estado desinfectando el medio ambiente eliminando todo lo que parece una definición de función bash durante más de una década. Desde Shellshock , otros entornos que ejecutan script de shell en un entorno no totalmente confiable han seguido su ejemplo.

No puede ejecutar de forma segura un script en un entorno que haya sido configurado por una entidad no confiable. Por lo tanto, preocuparse por las definiciones de funciones no es productivo. Desinfecte su entorno y, al hacerlo, las variables que bash interpretarían como definiciones de funciones.

Puede usar unset -fpara eliminar las funciones incorporadas, comando y tipo.