Я читал знаменитую легенду восстановления Unix , и мне пришло в голову удивление:
Если бы у меня была открыта оболочка BusyBox, а двоичный файл BusyBox был удален сам, смогу ли я по-прежнему использовать все команды, включенные в двоичный файл BusyBox?
Ясно, что я не смог бы использовать версию BB этих команд из другой запущенной оболочки, например bash
, так как сам файл BusyBox был бы недоступен для bash
открытия и запуска. Но из запущенного экземпляра BusyBox, мне кажется, может быть два метода, с помощью которых BB будет выполнять команду:
- Он может создать и выполнить новый экземпляр BusyBox, вызвав его с использованием соответствующего имени и прочитав для этого файл BusyBox с диска.
- Он может выполнить разветвление и выполнить некоторую внутреннюю логику для запуска указанной команды (например, запустив ее как вызов функции).
Если (1) работает BusyBox, я ожидаю, что некоторые команды, предоставленные BusyBox, станут недоступными из запущенного экземпляра BB после удаления двоичного файла BB.
Если (2) работает так, BusyBox можно использовать даже для восстановления системы, в которой был удален сам BB - при условии, что все еще доступен работающий экземпляр BusyBox.
Это где-нибудь задокументировано? Если нет, есть ли способ безопасно проверить это?
источник
is there a way to safely test it?
Загрузите общийopenwrt
образ x86 и прикрепите его к новой машине VirtualBoxPATH
сброса? Это принимает значение по умолчаниюPATH
?Ответы:
По умолчанию BusyBox не делает ничего особенного в отношении встроенных апплетов (команды указаны с помощью
busybox --help
).Однако, если
FEATURE_SH_STANDALONE
иFEATURE_PREFER_APPLETS
опции включены во время компиляции, а затем , когда BusyBox sh¹ выполняет команду , которая является известным апплетом имени, он не делает нормальныйPATH
поиск, но вместо этого запускает встроенный в апплетах через ярлык:chgrp
,chmod
,chown
,cksum
,cp
,cut
,dd
,dos2unix
,env
,fold
,hd
,head
,hexdump
,ln
,ls
,md5sum
,mkfifo
,mknod
,sha1sum
,sha256sum
,sha3sum
,sha512sum
,sort
,tac
,unix2dos
.[[
,[
,basename
,cat
,dirname
,echo
,false
,fsync
,length
,logname
,mkdir
,printenv
,printf
,pwd
,rm
,rmdir
,seq
,sync
,test
,true
,usleep
,whoami
,yes
.fork
иexecve
), но вместоPATH
поиска выполняется BusyBox/proc/self/exe
, если он доступен (что обычно имеет место в Linux), и путь, определенный во время компиляции в противном случае.Это задокументировано более подробно в
docs/nofork_noexec.txt
. Объявления апплета находятся вinclude/applets.src.h
исходном коде.В большинстве конфигураций по умолчанию эти функции отключены, поэтому BusyBox выполняет внешние команды, как и любая другая оболочка. Debian включает эти функции как в своих, так
busybox
и вbusybox-static
пакетах.Таким образом, если у вас есть исполняемый файл BusyBox, скомпилированный с
FEATURE_SH_STANDALONE
иFEATURE_PREFER_APPLETS
, то вы можете выполнить все команды BusyBox из оболочки BusyBox, даже если исполняемый файл удален (за исключением апплетов, которые не перечислены выше, если они/proc/self/exe
недоступны).¹ На самом деле в BusyBox есть две реализации «sh» - ash и hush - но они ведут себя одинаково в этом отношении.
источник
FEATURE_PREFER_APPLETS
иFEATURE_SH_STANDALONE
флаги времени компиляции, включающие или отключающие функции. Апплеты помеченыnofork
иnoexec
независимо от того, какие флаги были использованы. Будет ли такая маркировка иметь какой-либо эффект, зависит отFEATURE_PREFER_APPLETS
того, включена ли она. Следовательно, три возможных поведения: 1.FEATURE_PREFER_APPLETS
отключен, 2.FEATURE_PREFER_APPLETS
включен и апплетnofork
, 3.FEATURE_PREFER_APPLETS
включен и апплетnoexec
. Третий параграф в документации объясняет это хорошо. И последний раздел показывает возможные случаи.FEATURE_SH_STANDALONE
(которая требуетFEATURE_PREFER_APPLETS
).nofork
не нужен СFEATURE_SH_STANDALONE
,/proc/self/exe
используется там, где это применимо, поэтому он будет работать, даже если BB был удален . Вы можете проверить это с довольно минимальным риском на любом Debian или Arch Linux systm, запускаbusybox ash
,unset PATH
выполните команды Басина. Работает нормально.cat
ниchmod
не требует Exec-кий путь к файлу, вы можете восстановить исполняемый файл таким образом:cat /proc/self/exe > busybox; chmod 755 busybox
.tac
требуется либо доступный для поиска входной файл, который не всегда доступен, либо чтение всего ввода в память.cat
может прочитать его ввод от начала до конца, отбрасывая то, что он уже обработал. Его гораздо проще реализовать, и он также гораздо чаще используется, поэтому имеет смысл оптимизировать его.FEATURE_xxx
опция компиляции для BusyBox в целом Указания nofork и noexec имеют значение только в том случае, если ониFEATURE_PREFER_APPLETS
активны (по крайней мере, для выполнения команды в оболочке они также используются в некоторых других контекстах).is there a way to safely test it?
С помощью общего образа x86 openwrt:Большинство команд не являются встроенными, но некоторые, как
echo
иprintf
. Бинарный файл с произвольным содержимым может быть создан с использованиемprintf
, ноchmod +x
это будет проблемой.источник
/bin/ash -> busybox
.FEATURE_SH_STANDALONE
включено, вы не получите такое поведение. Второйmv
будет работать отлично.