Czy polecenia BusyBox są naprawdę wbudowane?

Czytałem słynną Legendę odzyskiwania systemu Unix i przyszło mi do głowy, aby się zastanawiać:

Gdybym miał otwartą powłokę BusyBox, a sam plik binarny BusyBox zostałby usunięty, czy nadal będę mógł używać wszystkich poleceń zawartych w pliku binarnym BusyBox?

Oczywiście nie byłbym w stanie użyć wersji BB tych poleceń z innej działającej powłoki, takiej jak bash, ponieważ sam plik BusyBox byłby niedostępny bashdo otwarcia i uruchomienia. Ale z działającej instancji BusyBox wydaje mi się, że mogą istnieć dwie metody, za pomocą których BB uruchamia polecenie:

1. Może rozwidlać i wykonywać nową instancję BusyBox, wywołując ją przy użyciu odpowiedniej nazwy - i w tym celu odczytując plik BusyBox z dysku.
2. Może rozwidlać i wykonywać wewnętrzną logikę, aby uruchomić określone polecenie (na przykład uruchamiając je jako wywołanie funkcji).

Jeśli (1) jest sposobem działania BusyBox, oczekiwałbym, że niektóre polecenia dostarczone przez BusyBox staną się niedostępne z działającej instancji BB po usunięciu pliku binarnego BB.

Jeśli (2) działa, BusyBox może być użyty nawet do odzyskania systemu, w którym usunięto sam BB - pod warunkiem, że nadal dostępna jest działająca instancja BusyBox.

Czy jest to gdziekolwiek udokumentowane? Jeśli nie, czy istnieje sposób na bezpieczne przetestowanie?

Domyślnie BusyBox nie robi nic specjalnego w odniesieniu do wbudowanych apletów (komendy wymienione jako busybox --help).

Jeśli jednak opcje FEATURE_SH_STANDALONEi FEATURE_PREFER_APPLETSsą włączone w czasie kompilacji, to gdy BusyBox sh¹ wykonuje polecenie o znanej nazwie apletu, nie wykonuje normalnego PATHwyszukiwania, ale uruchamia wbudowane aplety za pomocą skrótu:

• Aplety zadeklarowane w kodzie źródłowym jako „noexec” są wykonywane jako wywołania funkcji w procesie rozwidlenia. Począwszy od BusyBox 1,22 następujące Programy te są noexec: 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.
• Aplety zadeklarowane jako „nofork” w kodzie źródłowym są wykonywane jako wywołania funkcji w tym samym procesie. Począwszy od BusyBox 1,22 następujące Programy te są nofork: [[, [, basename, cat, dirname, echo, false, fsync, length, logname, mkdir, printenv, printf, pwd, rm, rmdir, seq, sync, test, true, usleep, whoami, yes.
• Inne aplety są naprawdę wykonywane (za pomocą forki execve), ale zamiast PATHwyszukiwania, BusyBox wykonuje się /proc/self/exe, jeśli są dostępne (co zwykle ma miejsce w Linuksie), a ścieżka jest zdefiniowana w innym czasie.

Jest to udokumentowane bardziej szczegółowo w docs/nofork_noexec.txt. Deklaracje apletów znajdują się w include/applets.src.hkodzie źródłowym.

Większość domyślnych konfiguracji wyłącza te funkcje, dzięki czemu BusyBox wykonuje polecenia zewnętrzne, jak każda inna powłoka. Debian włącza te funkcje zarówno w swoim pakiecie, jak busyboxi w busybox-staticpakietach.

Więc jeśli masz skompilowany plik wykonywalny BusyBox, FEATURE_SH_STANDALONEi FEATURE_PREFER_APPLETSmożesz wykonać wszystkie polecenia BusyBox z powłoki BusyBox, nawet jeśli plik wykonywalny jest usunięty (z wyjątkiem apletów, które nie są wymienione powyżej, jeśli /proc/self/exenie są dostępne).

¹ _{W BusyBox istnieją dwie implementacje „sh” - ash i hush - ale pod tym względem zachowują się tak samo.}

is there a way to safely test it? Z ogólnym obrazem openwrt x86:

Większość poleceń nie jest wbudowana, ale niektóre są takie jak echoi printf. Plik binarny z dowolną zawartością można utworzyć za pomocą printf, ale chmod +xbędzie to problem.