BusyBox komutları gerçekten yerleşik mi?

Ünlü Unix Kurtarma Efsanesini okuyordum ve şunu merak ettim:

Açık bir BusyBox kabuğum olsaydı ve BusyBox ikilisinin kendisi silinmiş olsaydı, hala BusyBox ikilisinde bulunan tüm komutları kullanabilir miydim?

Açıkçası ben gelenler komutların BB sürümünü kullanmak mümkün olmaz başka gibi çalışan kabuk bashBusyBox Dosyanın kendisi için kullanılamaz olacaktır çünkü bashaçık ve run. Ancak BusyBox'un çalışan örneğinden, bana öyle geliyor ki, BB'nin bir komutu çalıştırması için iki yöntem olabilir:

1. Yeni bir BusyBox örneğini çatallayabilir ve çalıştırabilir, uygun adı kullanarak çağırabilir ve BusyBox dosyasını diskten okuyabilir.
2. Belirtilen komutu çalıştırmak için bir içsel mantık kurabilir ve gerçekleştirebilir (örneğin, işlev çağrısı olarak çalıştırarak).

(1) BusyBox'ın çalışma şekliyse, BB ikili dosyası silindikten sonra belirli bir BusyBox tarafından sağlanan komutların çalışan bir BB örneği içinden kullanılamayacağını umardım.

(2) nasıl çalışırsa, BusyBox, hala BB'nin silindiği bir sistemin kurtarılması için bile kullanılabilir - hala çalışan bir BusyBox örneği mevcut olması koşuluyla.

Bu herhangi bir yerde belgeleniyor mu? Değilse, güvenle test etmenin bir yolu var mı?

Varsayılan olarak, BusyBox yerleşik olduğu uygulamalarla ilgili özel bir şey yapmaz (ile listelenen komutlar busybox --help).

Bununla birlikte, FEATURE_SH_STANDALONEve FEATURE_PREFER_APPLETSseçenekleri derleme zamanında etkinse, BusyBox bilinen bir uygulama adı olan bir komutu çalıştırdığında normal PATHaramayı yapmaz , bunun yerine yerleşik uygulamalarını kısayoldan çalıştırır:

• Kaynak kodunda "noexec" olarak bildirilen aparatlar, çatallı bir işlemde fonksiyon çağrıları olarak yürütülür. BusyBox 1.22 itibariyle, aşağıdaki uygulamalar noexec şunlardır: 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.
• Kaynak kodunda “nofor” olarak bildirilen aparatlar aynı süreçte fonksiyon çağrıları olarak yürütülür. BusyBox 1.22 itibariyle, aşağıdaki uygulamalar nofork şunlardır: [[, [, basename, cat, dirname, echo, false, fsync, length, logname, mkdir, printenv, printf, pwd, rm, rmdir, seq, sync, test, true, usleep, whoami, yes.
• Diğer uygulamalar gerçekten (ile forkve ile execve) yürütülür , ancak bir PATHarama yapmak yerine /proc/self/exe, varsa (normalde Linux'ta olduğu gibi) BusyBox , aksi takdirde derleme zamanında tanımlanmış bir yolu çalıştırır.

Bu, içinde biraz daha ayrıntılı olarak belgelenmiştir docs/nofork_noexec.txt. Uygulama bildirimleri include/applets.src.hkaynak kodundadır.

Çoğu varsayılan yapılandırma bu özellikleri kapatır, böylece BusyBox herhangi bir kabuk gibi harici komutları çalıştırır. Debian onun hem bu özellikleri açar busyboxve busybox-staticpaketler.

Yani bir BusyBox yürütülebilir ile derlenmiş varsa FEATURE_SH_STANDALONEve FEATURE_PREFER_APPLETS(eğer yukarıda yer almayan uygulamaları haricinde o zaman yürütülebilir silinmiş olsa bile bir BusyBox kabuğundan tüm BusyBox komutları yürütebilirsiniz, /proc/self/exemevcut değildir).

Y BusyBox'ta _{aslında "sh" nin iki uygulaması var - kül ve sus - ama bu açıdan aynı şekilde davranıyorlar.}

is there a way to safely test it? Genel x86 openwrt görüntüsü ile:

Komutların çoğu yerleşik değildir, ancak bazıları echove gibidir printf. Keyfi içeriği olan bir ikili dosya kullanılarak oluşturulabilir printf, ancak chmod +xbir problem olacaktır.