root が "/bin/rm -rf /" をしたらどうなるのか？
last modified: Feb 16, 2000
UNIX で root が "/bin/rm -rf /" をした場合の結末として、 以下のようになるという主張を実際に見たり聞いたりしたことがあるのですが、 全て明らかに誤りです。 信じてはいけません。
- /bin/rm が消えた時点で、rm のプロセス自体が異常終了する。 （なんでやねん！ ...まあ、SVR2, 4.1BSD では /bin/rmdir が消えたら止まると思うけど。）
- dynamic library が消えた後に rm のプロセスや動作中のコマンドが 異常終了する。 （なんでやねん！）
- それまで動いていたコマンド（デーモン類）が、 コマンドファイルが消えた後に終了する。 （なんでやねん！）
- カーネルが unlink(2) された時点で、システムがクラッシュする。 （なんでやねん！）
- open されたファイルを unlink すると、ファイルの内容を参照できるのは sync(2) されるまでであり、updated(8) と競争することになる。 （なんでやねん！）
- rm コマンドのファイル「だけ」が残る。（rm が残る環境はあり得るが、そこでは他にも沢山のものが残らなければ変。）
このページの目的は、 具体的な実験例で "rm -rf /" の結末を示すことで、 UNIX カーネルの semantics （振舞い）を確認し、 デマを払拭することにあります。
病的な例外を除けば、基本的には、"rm -rf /" すると、
- mount point （/ を含む）
- read-only の file system
- 空でないディレクトリ （そこが空でない理由は、ここの３項が再帰的に適用される）
Linux での実行例
以下に述べるのは、Slackware 3.1 on Linux 2.0.35 で実行してみた結果です。 実行後、ディスプレイのスナップショットを撮ってみたので参考にしてください。 ext247 というのは "/bin/rm -rf /" される機械のホスト名で、 sras70 というのは外部から種々の監視をしてくれた機械のホスト名です。
左下の xterm の窓で、"/bin/rm -rf /" を実行してみた ら、/proc だけが残りました。
注：/usr, /var などを独立したパーティションにせず、 / 以下を単一のパーティションにしていました。 もし複数のパーティションを mount していたら、 mount point （や、そこに至るパス）も rmdir(2) されずに残っていたはずです。右は top を実行中の窓であり、daemon 類や様々なコマンドが動作している （少なくとも終了していない）ことがわかります。 左上は、監視用の sras70 という機械で動いているシェルの窓ですが、
- あらかじめ ext247:/ を sras70:/mnt に NFS mount しておいたのだが、 ext247 の nfsd は正常に動作していて、ls などが普通にできる。 また、実際に /proc 以外のファイルはディレクトリからは 消えているものの、 df で見ると 7M ほどのブロックが解放されていない。
- ext247 は ping に応答する
- ext247 の echo server （inetd 埋め込み）は動作している
この後、X server を終了して端末から logout すると、 コンソールにはメッセージも何も出ず、 キーを押しても無反応な状態になりました。 しかし、nfs server や daemon 類は動作し続けており、 監視している sras70 から df してみることは普通にできます。 やってみると、 終了したコマンドや close されたファイルに相当する分のブロックが 解放されて、使用中の領域が減っていました。
ちなみに、Slackware の rm は GNU fileutils 由来です。
より詳細には、以下の情報を参照してください。
- "rm -rf /" を実行したときの端末への出力
- 外部から監視していた機械上のログ
- "rm -rf /" 直前の "find / -ls" の出力 (gzip による圧縮:約 277KBytes)
FreeBSD での実行例
以下に述べるのは、FreeBSD 2.2.5-RELEASE で実行してみた結果です。 実行後、ディスプレイのスナップショットを撮ってみたので参考にしてください。 ext247 というのは "/bin/rm -rf /" される機械のホスト名で、 sras70 というのは外部から種々の監視をしてくれた機械のホスト名です。
結果は Linux とほとんど同じです。 左下の xterm の窓で、"rm -rf /" を実行してみた ら、/kernel と /proc だけが残りました。
注：右は top を実行中の窓であり、daemon 類や様々なコマンドが動作している （少なくとも終了していない）ことがわかります。 左上は、監視用の sras70 という機械で動いているシェルの窓ですが、
- /usr, /var などを独立したパーティションにせず、 / 以下を単一のパーティションにしていました。 もし複数のパーティションを mount していたら、 mount point （や、そこに至るパス）も rmdir(2) されずに残っていたはずです。
- kernel が消えないのは、schg flag がセットされているからです。 (see. chflags(1))。 これをクリアしておいたなら unlink されていたでしょう。 （動作中にカーネルのファイルを消すことは可能であり、 やっても何ら問題がない。）
- あらかじめ ext247:/ を sras70:/mnt に NFS mount しておいたのだが、 ext247 の nfsd は正常に動作していて、ls などが普通にできる。 また、実際に /proc 以外のファイルはディレクトリからは 消えているものの、 df で見ると 8M ほどのブロックが解放されていない。
- ext247 は ping に応答する
- ext247 に smtp で接続することができる。
この後、X server を終了して端末から logout すると、 コンソールにはメッセージも何も出ず、 キーを押しても無反応な状態になりました。 それでも、監視している sras70 からは、 カーネルやデーモン類が動作し続けていることが確認できました。 df してみると、 終了したコマンドや close されたファイルに相当する分のブロックが 解放されて、使用中の領域が減っていました。
ちなみに、FreeBSD の rm は 4.4BSD Lite-2 由来です。
より詳細には、以下の情報を参照してください。
- "rm -rf /" を実行したときの端末への出力
- オープンされているファイルの一覧を lsof で調べた結果
- "rm -rf /" の直前に lsof した結果 。
- "rm -rf /" の後に lsof した結果 。 ただし、lsof を含めて若干のコマンドを置いたり、 /cdrom をマウントして適当なリンクを張ったりした後である。
- X サーバーを終了させた後に lsof した結果 。
- 外部から監視していた機械上のログ
- "rm -rf /" 直前の "find / -ls" の出力 (gzip による圧縮:約 123KBytes)
- "rm -rf /" 後、
全ての端末から logout した状態で突然電源を切り、
他のファイルシステムから reboot して
fsck をかけた結果;
--- 電源を切った時点で何らかのプロセスが参照していた inode については 何らか（典型的には UNREF FILE）のエラーが出るはず。 なぜなら、その inode はディスク上にまだ存在していたのに、 対応するディレクトリエントリがなくなってしまっているのであるから。
BSD 由来のＯＳでは、FFS のディレクトリへの書き込みは 同期的に行われることに注意。ただし、FreeBSD の場合、 このことは mount(8) で async option を指定しない 限りにおいて正しい。
こうして、 電源を切った時点において参照されていたファイル群 を割出すこともできる。
反省
追試をなさる方は以下にご注意ください。
- syslogd の出力は、遠隔の loghost に振り替えておくべきだったなあ。
- "rm -rf /" は time にかけて、使った計算機資源を見ておくべきだったなあ。
- コンソールの窓を出しておいて、何かメッセージが出るか監視すべきだったなあ。 FreeBSD では、コンソール用の xterm で top を走らせてしまった。 ただし、X を終了した時点でコンソールに変なメッセージが出ていないことは 確認してあるので、大丈夫だと思う。
- FreeBSD でテストするとき、"/bin/rm" のようにパスを明示しわすれてたなあ。 もちろん、怪しい alias を設定したり、 自前の変態な「バックアップ付き rm スクリプト」などに置き換えたりはしていない。 標準の /bin/rm がインストールされていただけである。
- Linux でも uname -a した結果をスクリーンに出しておけばよかったなあ。
future work
このページは、理論的な考察よりも、 実際に実験してみた結果を報告することに集中しています。 今後は、System V 系の機械での実験が望まれます。 System V 系では、 実行中のコマンドのファイルを unlink しようとすると ETXTBSY になるはずで、 多数のファイルやディレクトリが残ることが見込まれます。
参考文献
- rm に関する過去のニュース記事
- どうして open, mmap(dynamic lib), execve されたファイルを unlink しても ブロックはすぐには解放されないのか、 kernel を削除してもかまわないのは何故か等、 このページの実験の背景となる UNIX システムの振舞いの解説。
- rm(1) のソース
-
実はこれをみても、UNIX システムの振舞いはあまりわからないとは思う。
- GNU の sh-utils に由来する Slackware の rm(1) のソースコード
- FreeBSD の rm(1) のソースコード
文責：渡邊克宏
誤りの指摘や質問、感想あるいは関連する情報の提供を歓迎します。
katsu@watanabe.name