Чи справді вбудовані команди BusyBox?

Я читав знамениту легенду про відновлення Unix , і мені спало на думку цікаво:

Якби у мене була відкрита оболонка BusyBox, а сам двійковий файл BusyBox був видалений, я все-таки зможу використовувати всі команди, що входять у двійковий файл BusyBox?

Зрозуміло, я не зможу використовувати BB-версію цих команд з іншої запущеної оболонки, наприклад bash, оскільки сам файл BusyBox був би недоступний для bashвідкриття та запуску. Але зсередини запущеного примірника BusyBox, мені здається, може існувати два методи, за допомогою яких BB запускає команду:

1. Він може розщедрити і виконати новий екземпляр BusyBox, викликавши його, використовуючи відповідне ім'я - та прочитавши файл BusyBox з диска для цього.
2. Він може розщедритися і виконати деяку внутрішню логіку для запуску зазначеної команди (наприклад, запустивши її як виклик функції).

Якщо (1) працює таким чином BusyBox, я б очікував, що певні команди, надані BusyBox, стануть недоступними в запущеному екземплярі BB після видалення бінарного BB.

Якщо (2) це працює, BusyBox можна було б використовувати навіть для відновлення системи, де був видалений сам BB - за умови, що все ще доступний запущений екземпляр BusyBox.

Це десь задокументовано? Якщо ні, чи є спосіб безпечно перевірити його?

За замовчуванням BusyBox не робить нічого особливого щодо вбудованих аплетів (команди, перелічені з busybox --help).

Однак якщо параметри FEATURE_SH_STANDALONEта FEATURE_PREFER_APPLETSпараметри включені під час компіляції, тоді, коли BusyBox sh¹ виконує команду, яка є відомим іменем аплету, вона не робить звичайного PATHпошуку, а замість цього виконує вбудовані аплети через ярлик:

• Аплети, які у вихідному коді оголошені як "noexec", виконуються як виклики функцій у роздвоєному процесі. Станом BusyBox 1,22, такі аплети поехес: 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.
• Аплети, які у вихідному коді оголошені як "nofork", виконуються як виклики функцій у тому ж процесі. Станом BusyBox 1,22, такі аплети nofork: [[, [, 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вони недоступні).

¹ _{Насправді є дві реалізації "sh" у BusyBox - ash та hush - але вони поводяться однаково в цьому відношенні.}

is there a way to safely test it? З загальним зображенням x86 openwrt:

Більшість команд не є вбудованими, але деякі є, як echoі printf. Бінарний файл з довільним вмістом можна створити за допомогою printf, але chmod +xце буде проблемою.