rm コマンドにそのようなセーフガードがないのはなぜですか?
すでに 3 つのセーフガードがあります:
-r
スイッチなしではディレクトリを削除できません。-i
これは、削除するように要求したものを実際に削除したいことを確認します。エイリアシングrm
rm -i
まで-f
を追加しない限り、そのセーフガードをオンにします スイッチをオフにします。- ファイルの所有権。これにより、
root
以外のすべてのユーザーがアクセスできなくなります ルート ディレクトリの削除を防ぎます。
Unix のツールセットはチェーンソーのようなものです。非常に強力な機能を実行できるように設計されており、自分が何をしているのかを理解している人が使用できるようになっています。不用意に踏む人は、けがをする可能性があります。これは、経験豊富な人が間違いを犯さないと言っているわけではありません。明らかに、Sun やその他の人々は、root
を持つユーザーは 自分自身から保護する必要があります。
しかし、この特定のケースはその規則の例外であってはなりませんか?
なぜ rm
にブレード ガードを付けられないのかという質問が寄せられています 少なくとも 1980 年代からのチェーンソー。 (おそらくもっと長いかもしれませんが、私の Unix の歴史はそれ以上さかのぼることはありません。) もっと自問自答する必要があります:
-
例外を追加しているので、他に何を神聖と見なす必要がありますか?
rm -rf /*
のような同様に壊滅的なミスを避けるために、ルート ディレクトリ内の何かを再帰的に削除することを防止する必要があります。 ?ユーザーのホーム ディレクトリはどうでしょうか。/lib
はどうですか または/bin
?rm
の特別なバージョンが必要ですか? 非伝統的なファイル システム レイアウトのシステムでこれらの間違いを防ぐには? -
これらの禁止事項の実施をどこに置くか?ちょうど
は、システムが既に完了していることを意味します。rm
それとも、カーネルにその仕事を与えますか?rm
以降 実際には何も削除しません (unlink(2)
を何度も呼び出します) とrmdir(2)
引数に基づいて)、カーネルがそのrm
を検出する方法はありません。/
を狙っていた 実際に削除する瞬間まで。rmdir(2)
への唯一の呼び出し以降 成功するのは、ターゲットディレクトリが空で、/
でそのポイントに到達する場合です
ディストリビューションによって異なります。私が現在使用している古い Linux では、それが許可されており (テストはしていないと思いますが :-) )、man rm
に記載されています。 :
--no-preserve-root do not treat '/' specially (the default)
--preserve-root
fail to operate recursively on '/'
最近の多くのディストリビューションでは、明示的に --no-preserve-root
を追加する必要があります セーフガードを無効にします。そうしないと、実行に失敗します。
Ubuntu に関しては、この動作が議論されているこの問題を参照してください。
ウィキペディアによるこの保護の歴史:
<ブロック引用>
Sun Microsystems が rm -rf /
を導入 コマンドを実行すると、システムは /
の削除を報告するようになりました。 許可されていません。その後まもなく、同じ機能が rm
の FreeBSD バージョンに導入されました。 効用。 GNU rm
rm -rf /
の実行を拒否します --preserve-root
の場合 2006 年に GNU Core Utilities のバージョン 6.4 がリリースされて以来、これがデフォルトになっています。