rm -rf /
を実行すると、システムが実際にどこまで到達するのかとよく疑問に思いました。 OSが自分自身を消去できるとは思えません(?)
ボーナス質問:コマンドが実行された後、rm
はそれ自体を削除しますか?
更新:私はVirtualBoxを使用していくつかの主要なUNIXディストリビューションでこれをテストしましたが、答えは何が起こるかを正確に説明しています。正しいパラメータを指定すると、rmはディスク上のデータのすべての物理ビットを削除します。ただし、GNU 1以外のバージョンのrmを使用すると、いくつかの問題が発生しました。たとえば、BusyBoxには独自のバージョンがあり、削除することができません。可能性があります。
この質問は今週のスーパーユーザーの質問でした。
詳細については、2011年7月7日を読むブログエントリまたは自分で送信今週の質問。
GNU coreutilsからのrm
がある場合(おそらく通常のLinuxディストリビューションの場合)、rm -rf /
は組み込みの保護機能によって拒否されます(マンページによるととウィキペディア、それを試していません)。
この保護は--no-preserve-root
で上書きできます。 rm
は、すべてのファイルを削除しようとした後に停止することなく、可能な限りすべてを削除します。もちろん、それは/proc
や/sys
のような仮想ファイルシステムを削除しませんが、それは無関係です。ディスク上のすべてを削除します。
コマンドが完了すると、OSを含め、ディスクは空にワイプされます。カーネルと現在のプロセスは引き続きメモリから実行されますが、一部のファイルへのアクセスに失敗するため、多くのプロセスが停止します。 OSは次回の起動に失敗します。
VMを設定してお楽しみください。
それはかなり遠くまで行きます... GUIを使用している場合、物事がより目に見えて低下することに気づく楽しみがあるかもしれません。 (メニューのアイコンがロードを停止するなど)
手放すと、一部のデータを簡単に戻すことができるかもしれませんが、OSはほとんどリカバリを超えます。
どちらの場合も、OSの再インストールを行う必要があります。
さて、 http://bellard.org/jslinux/ で試してみると、
rm: '/ dev/pts'を削除できません:デバイスまたはリソースがビジーです
rm: '/ dev'を削除できません:ディレクトリが空ではありません
rm: '/ proc/swaps'を削除できません:操作は許可されていません
rm: '/ proc/kallsyms'を削除できません:操作は許可されていません
rm: '/ proc/dma'を削除できません:操作は許可されていませんSNIP 881エントリ
rm: '/ proc/149/oom_adj'を削除できません:権限が拒否されました
rm: '/ proc/149'を削除できません:操作は許可されていません
rm: '/ proc'を削除できません:デバイスまたはリソースがビジーです
rm: '/ tmp'を削除できません:デバイスまたはリソースがビジーです
rm: '/'を削除できません:デバイスまたはリソースがビジーです
私はこれがalt.sysadmin.recovery
昔の昔、/proc
、/dev
は、異常なiノードの束のエントリを含む通常のディレクトリでした...
...しかし、Unixの一部のバリアント(私の記憶はHP-UXですが、それは完全に間違っている可能性があります)では、not実行中のプログラムの最後のディレクトリエントリを削除できます。 (共有ライブラリ?それらは何ですか?)
そのようなシステムで、1つをメンテナンスモードで起動して(シェル以外に何も実行されておらず、init
も使用されておらず、セカンダリファイルシステムがマウントされていなかった場合)、exec /bin/rm -rf /
、完全に空のルートファイルシステムが残るexcept that /bin
および/bin/rm
は存続します。
恐ろしい悪魔修道院の住人たちはこれを適切で適切であると考えました。
rm -rf /
POSIX標準に違反していることが示唆されているため、最近の実装では許可しないでください。
とにかく、結局、仕様が変更され、Solaris 10には(ビルド36以降)/ usr/bin/rm(/ binはSolarisでは/ usr/binへのシンボリックリンク)と/ usr /のバージョンがあります。このように動作するxpg4/bin/rm:
[28] /bin/rm -rf / rm of / is not allowed [29]
他の人が作成したとは思わなかった1つのポイント:現在開いているファイル(たとえば、rm自体)は、削除されても、ドライブが閉じられるまで実際には消えません。
あなたがどこまで到達できるかは、基本的に特定のUnix/Linuxディストリビューションに依存します。
しかし、基本的な質問に答えるために、はい-rm
コマンドは、/bin
および他のフォルダー内の他の標準コマンドとともに削除されます。
これは、VMを使用してLinux Ubuntu 15.04で実行した簡単なテストです。
vagrant
を介して仮想マシンを初期化します:
vagrant init ubuntu/vivid64 && vagrant up --provider virtualbox && vagrant ssh
次に、すべてのファイルを標準的な方法で削除しようとすると、次のことができません。
vagrant@vagrant-ubuntu-vivid-64:~$ Sudo rm -fr /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe
--no-preserve-root
を試してみましょう。仮想マシンにログインしていることを常に再確認し(vagrant@vagrant-ubuntu-vivid-64:~$
を使用しているため)、次に実行します(自宅で試さないでください)。
vagrant@vagrant-ubuntu-vivid-64:~$ Sudo rm -vfr --no-preserve-root /
removed directory: '/lost+found'
removed directory: '/opt'
removed '/bin/nc'
removed '/bin/less'
removed '/bin/wdctl'
removed '/bin/nano'
...
removed '/bin/rmdir'
removed '/bin/sh'
removed '/bin/rm'
...
removed directory: '/bin'
removed directory: '/usr/games'
removed '/usr/bin/byobu-launcher-install'
removed '/usr/bin/ipcmk'
removed '/usr/bin/sum'
removed directory: '/usr/bin'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9.2'
removed '/usr/lib/gcc/x86_64-linux-gnu/5.0.1'
removed directory: '/usr/lib/gcc/x86_64-linux-gnu/5'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9/libquadmath.so'
removed '/usr/lib/gcc/x86_64-linux-gnu/4.9/libgomp.so'
...
removed directory: '/run/initramfs'
removed directory: '/media'
rm: cannot remove '/proc/fb': Operation not permitted
rm: cannot remove '/proc/fs/ext4/sda1/options': Operation not permitted
...
removed '/vmlinuz'
removed '/boot/config-3.19.0-23-generic'
removed '/boot/grub/grubenv'
...
removed directory: '/boot'
removed '/lib64/ld-linux-x86-64.so.2'
rm: cannot remove '/dev/hugepages': Device or resource busy
rm: cannot remove '/dev/mqueue': Device or resource busy
rm: cannot remove '/dev/shm': Device or resource busy
removed '/dev/vcsa7'
...
removed '/dev/mem'
removed '/dev/rfkill'
removed '/dev/vga_arbiter'
...
rm: cannot remove '/sys/fs/ecryptfs/version': Operation not permitted
removed directory: '/etc'
removed directory: '/mnt'
removed '/vagrant/.vagrant/machines/default/virtualbox/action_provision'
removed '/vagrant/.vagrant/machines/default/virtualbox/action_set_name'
removed '/vagrant/.vagrant/machines/default/virtualbox/creator_uid'
removed '/vagrant/.vagrant/machines/default/virtualbox/id'
removed '/vagrant/.vagrant/machines/default/virtualbox/index_uuid'
removed '/vagrant/.vagrant/machines/default/virtualbox/private_key'
removed '/vagrant/.vagrant/machines/default/virtualbox/synced_folders'
removed directory: '/vagrant/.vagrant/machines/default/virtualbox'
removed directory: '/vagrant/.vagrant/machines/default'
removed directory: '/vagrant/.vagrant/machines'
removed directory: '/vagrant/.vagrant'
removed '/vagrant/Vagrantfile'
rm: cannot remove '/vagrant': Device or resource busy
その後、何も起こらなかったようにシェルプロンプトに戻りますが、組み込みコマンドとkill
を除いて、コマンドを実行できなくなるため、ジョブを完了してセッションを終了できます。
例えば:
$ rm
rm: command not found
$ kill
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
$ which kill
-bash: /usr/bin/which: No such file or directory
$ kill -9 $$
Connection to 127.0.0.1 closed.
そのため、rm
、ls
、およびその他のすべてのコマンドを含むすべてがかなり削除されましたが、まだログインしています。 /dev
、/proc
、/sys
の一部のデバイスなど、削除されなかった特別なフォルダーがいくつかありますが、これらは通常のディレクトリ/ファイルではありませんが、擬似ファイルシステムがプロセスとカーネルデータ。
VagrantまたはLinuxがない場合は、いくつかの JavaScript Linux x86エミュレーター で遊ぶことができます。
このような災害からの回復の可能性に興味がある場合は、以下を確認してください。
ターミナルでrootとしてログインして(私を怒らせているサーバーで)一度試したため、ほとんどすべてが失われます。消去されないのは、OSに不可欠なプロセスだけです。