Как явно и безопасно форсировать использование встроенной команды в bash

Есть похожий вопрос, который касается сценария «обтекания», где вы хотите заменить, например, cdкоманду, которая вызывает встроенную функцию cd.

Тем не менее, в свете shellshock и др. И зная, что bash импортирует функции из среды, я провел несколько тестов и не могу найти способ безопасного вызова встроенной функции cdиз моего скрипта.

Учти это

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

Любые скрипты, вызываемые в этой среде, cdбудут ломаться (учитывайте эффекты чего-то вроде cd dir && rm -rf .).

Существуют команды для проверки типа команды (удобно называются type) и команды для выполнения встроенной версии, а не функции ( builtinи command). Но, о чудо, они также могут быть переопределены с помощью функций

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

Даст следующее:

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

Есть ли способ безопасно заставить bash использовать встроенную команду или, по крайней мере, обнаружить, что команда не является встроенной, без очистки всей среды?

Я понимаю, что если кто-то контролирует вашу среду, вы, вероятно, все равно испорчены, но, по крайней мере, для псевдонимов у вас есть возможность не вызывать псевдоним, вставив \перед ним.

Оливье Д почти правильный, но вы должны установить POSIXLY_CORRECT=1перед запуском unset. POSIX имеет понятие специальных встроенных модулей , и bash поддерживает это . unsetявляется одним из таких встроенных. Искать SPECIAL_BUILTINв builtins/*.cв источнике Баш для списка, он включает в себя set, unset, export, evalи source.

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

Мошенник unsetтеперь был удален из среды, если сбросить command, type, builtinто вы должны быть в состоянии продолжать, но unset POSIXLY_CORRECTесли вы полагаетесь на не-POSIX поведения или расширенные функции Баш.

Однако это не относится к псевдонимам, поэтому вы должны использовать его, \unsetчтобы убедиться, что он работает в интерактивной оболочке (или всегда, если expand_aliasesон действует).

Для параноика это должно все исправить, я думаю:

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, doneИ [[являются зарезервированными словами и не нужны меры предосторожности.) Обратите внимание , что мы используем , unset -fчтобы быть уверенным в неустановленных функций, хотя переменные и функции разделяют то же пространство имен , что это возможно для обоих существовать одновременно (благодаря Этан Рейснер) , в этом случае Отмена дважды также сделает свое дело. Вы можете пометить функцию только для чтения, bash не мешает вам отключить функцию readonly вплоть до bash-4.2, bash-4.3 предотвращает вас, но она по-прежнему учитывает специальные встроенные функции, когда POSIXLY_CORRECTона установлена.

Чтение только POSIXLY_CORRECTне является реальной проблемой, это не логическое значение или флаг, при котором его наличие активирует режим POSIX, поэтому, если он существует как доступный только для чтения, вы можете полагаться на функции POSIX, даже если значение пустое или равно 0. Вам просто нужно сбрасывать проблемные функции другим способом, чем описано выше, возможно, с помощью функции вырезания и вставки:

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

(и игнорировать любые ошибки) или участвовать в некоторых других сценариях .

Другие заметки:

• functionявляется зарезервированным словом, оно может быть псевдонимом, но не может быть переопределено функцией. (Псевдоним functionмягко неприятен, потому что \function не подходит для его обхода)
• [[, ]]являются зарезервированными словами, они могут быть псевдонимами (которые будут игнорироваться), но не могут быть переопределены функцией (хотя функции могут быть названы так)
• (( не является допустимым именем для функции или псевдонимом

Я понимаю, что если кто-то контролирует вашу среду, вы, вероятно, все равно облажались

Да, это. Если вы запускаете скрипт в неизвестной среде, все может пойти не так, начиная с того, LD_PRELOADчто процесс оболочки выполнит произвольный код еще до того, как он прочитает ваш скрипт. Попытка защитить от враждебной среды изнутри сценария тщетна.

Sudo очищает окружающую среду, удаляя все, что похоже на определение функции bash, уже более десяти лет. Начиная с Shellshock , другие среды, которые запускают сценарий оболочки в среде, не являющейся полностью доверенной, следовали этому примеру.

Вы не можете безопасно запускать сценарий в среде, которая была установлена ​​ненадежным объектом. Поэтому беспокоиться об определениях функций не является продуктивным. Очистите вашу среду, и при этом переменные, которые bash будет интерпретировать как определения функций.

Вы можете использовать unset -fдля удаления встроенных функций, команды и типа.