BusyBoxコマンドは本当に組み込まれていますか?


28

私は有名なUnix Recovery Legendを読んでいたのですが、次のことを知りました:

BusyBoxシェルを開いていて、BusyBoxバイナリ自体が削除された場合でも、BusyBoxバイナリに含まれるすべてのコマンドを使用できますか?

BusyBoxファイル自体を開いて実行することはできないため、明らかに、のような別の実行中のシェルからこれらのコマンドのBBバージョンを使用bashすることはできませんbash。しかし、BusyBoxの実行中のインスタンス内からは、BBがコマンドを実行する2つの方法があるように思えます。

  1. BusyBoxの新しいインスタンスを分岐して実行し、適切な名前を使用して呼び出し、ディスクからBusyBoxファイルを読み取ります。
  2. 指定されたコマンドを実行するために、いくつかの内部ロジックを分岐して実行できます(たとえば、関数呼び出しとして実行することにより)。

(1)がBusyBoxの動作方法である場合、BBバイナリが削除された後、特定のBusyBoxが提供するコマンドがBBの実行中のインスタンス内から利用できなくなることが予想されます。

(2)が機能する場合、BB自体が削除されたシステムの復旧にもBusyBoxを使用できます(ただし、BusyBoxの実行中のインスタンスにアクセスできる場合)。

これはどこにも文書化されていますか?そうでない場合、安全にテストする方法はありますか?


2
is there a way to safely test it?一般的なx86のダウンロードopenwrtイメージをし、新しいVirtualBoxのマシンに画像を添付
流域

2
そして、これは疑問を提起します、Busyboxコマンドが設定解除された後、どのように機能し続けるのPATHですか?デフォルト値を想定していますPATHか?
ムル

2
@muru:ソースコード(少なくともそのアッシュクローン)からは、未設定のPATHを空の文字列と同じように扱うため、現在のディレクトリのみを検索します。
ヘニングマックホルム16

@HenningMakholmさて、私のコメントは、Gillesの答えで答えられました。しかし、それを知っているのは良いことです-私はビルトインだけが機能することを期待していました。
ムル

回答:


33

デフォルトでは、BusyBoxは組み込みのアプレット(にリストされているコマンドbusybox --help)に関して特別なことを行いません。

ただし、コンパイル時にFEATURE_SH_STANDALONEand FEATURE_PREFER_APPLETSオプションが有効になっている場合、BusyBoxsh¹は既知のアプレット名であるコマンドを実行すると、通常のPATHルックアップを実行せず、代わりにショートカットを使用して組み込みアプレットを実行します。

  • ソースコードで「noexec」として宣言されているアプレットは、分岐したプロセスで関数呼び出しとして実行されます。BusyBoxの1.22のように、次のアプレットがnoexecであります:chgrpchmodchowncksumcpcutdddos2unixenvfoldhdheadhexdumplnlsmd5summkfifomknodsha1sumsha256sumsha3sumsha512sumsorttacunix2dos
  • ソースコードで「nofork」として宣言されているアプレットは、同じプロセスで関数呼び出しとして実行されます。BusyBoxの1.22のように、次のアプレットはnoforkあります:[[[basenamecatdirnameechofalsefsynclengthlognamemkdirprintenvprintfpwdrmrmdirseqsynctesttrueusleepwhoamiyes
  • 他のアプレットは実際に(forkおよびでexecve)実行されPATHますが、BusyBoxはルックアップを実行する代わりに/proc/self/exe、利用可能な場合(通常はLinuxの場合)、コンパイル時に定義されたパスを実行します。

これについては、もう少し詳しく説明しdocs/nofork_noexec.txtます。アプレットの宣言はinclude/applets.src.hソースコードにあります。

ほとんどのデフォルト構成ではこれらの機能がオフになっているため、BusyBoxは他のシェルと同様に外部コマンドを実行します。Debianは、これらの機能busyboxbusybox-staticパッケージとパッケージの両方でオンにします。

したがって、FEATURE_SH_STANDALONEand FEATURE_PREFER_APPLETSでコンパイルされたBusyBox実行可能ファイルがある場合、実行可能ファイルが削除されていても、BusyBoxシェルからすべてのBusyBoxコマンドを実行できます(上記にリストされていないアプレットを除き/proc/self/exeます)。

¹BusyBoxには「ash」の実装が2つ(ashとhush)ありますが、この点では同じように動作します。


1
@Wildcard FEATURE_PREFER_APPLETSFEATURE_SH_STANDALONEはコンパイル時フラグであり、機能を有効または無効にします。アプレットにはマークが付けられnoforknoexecどのフラグが使用されたかには関係ありません。そのようなマーキングが効果を発揮するかどうかは、有効にするFEATURE_PREFER_APPLETSことによります。したがって、3つの可能な動作:1. FEATURE_PREFER_APPLETS無効、2。FEATURE_PREFER_APPLETS有効、アプレットはnofork、3。FEATURE_PREFER_APPLETS有効、アプレットはnoexecです。ドキュメントの3番目のパラグラフでは、適切に説明しています。そして、最後のセクションは可能なケースを示しています。
ムル

1
@Wildcard FEATURE_SH_STANDALONE(これにはが必要ですFEATURE_PREFER_APPLETS)。nofork必要ありません。ではFEATURE_SH_STANDALONE/proc/self/exe該当する場合に使用されるため、BBが削除された場合でも機能します。あなたは、任意のDebianやアーチのLinux systm、実行時にかなり最小限のリスクで、このうちをテストすることができbusybox ashunset PATH流域のコマンドを実行します。正常に動作します。
ムル

3
Ubuntu 14.04.1 LTSシステムでは、Busyboxはアプレットを優先するように構成されています。パス名の実行catchmod必要もないため、このようにして実行可能ファイルを回復できます cat /proc/self/exe > busybox; chmod 755 busybox
裸足IO

1
@forest大きな違いがありtacます。常に利用できるとは限らないシーク可能な入力ファイルを必要とするか、入力全体をメモリに読み込む必要があります。cat入力を最初から最後まで読み取り、処理済みのものを破棄できます。実装がはるかに簡単であり、より一般的に使用されているため、最適化する方が理にかなっています。
hvd

1
@Wildcard Noforkとnoexecは、各アプレットに設定された表示です。FEATURE_xxxBusyBox全体のコンパイル時オプションです。noforkとnoexecの表示FEATURE_PREFER_APPLETSは、アクティブである場合にのみ問題になります(少なくともシェルでコマンドを実行するために、これらは他のコンテキストでも使用されます)。
ジル 'SO-悪であるのをやめる'

8

is there a way to safely test it? 汎用のx86 openwrtイメージの場合:

vboxスクリーンショット

ほとんどのコマンドは、内蔵されていないが、いくつかのような、あるechoprintf。任意のコンテンツを持つバイナリファイルを使用して作成することができprintfますが、chmod +x問題になります。


面白い; BusyBox自体、または他のシェルから実行していますか?
ワイルドカード

4
(また、スクリーンショットではなくテキストに貼り付けてもよろしいですか?)
ワイルドカード

@Wildcard /bin/ash -> busybox
流域

1
Gillesの回答のように、FEATURE_SH_STANDALONEが有効になっている場合、この動作は得られません。2番目mvは完全に正常に動作します。
ムル
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.