なぜ chmod -R 777 / 破壊的ですか?

解決策 1:

まず第一に、マイナーな用語のつまらないもの:chmod 削除しない パーミッション。 変わる 彼ら。

さて、問題の核心 -- モード 777 「誰でもこのファイルの読み取り、書き込み、実行ができる」という意味 - 権限が与えられている 誰もが（効果的に）やりたいことを何でもできるように。

では、なぜこれが悪いのでしょうか?

<オール>

システム上のすべてのファイルの読み取りと変更を全員に許可しました。

パスワードセキュリティに別れを告げましょう (誰でもシャドウファイルを読み取ってパスワードを破ることができますが、わざわざパスワードを変更するだけです! はるかに簡単です!)
バイナリのセキュリティに別れを告げる (新しい login を書ける人がいる) いつでも参加できるプログラム）
ファイルに別れを告げる:1 人のユーザーが rm -r / を誤って転送そしてそれはすべて終わった。 OS は、彼らがやりたいことを何でもするように言われました!

開始前にファイルのアクセス許可をチェックするすべてのプログラムに腹を立てています。
sudo 、 sendmail 、およびその他のホストは、単に起動しなくなります。彼らは重要なファイルのパーミッションを調べ、本来あるべきものではないことを確認し、エラーメッセージを返します。
同様に ssh ひどく壊れます (鍵ファイルには特定のパーミッションが必要です。そうでない場合、それらは「安全ではなく」、デフォルトで SSH はそれらの使用を拒否します)。

プログラムの setuid / setgid ビットを消去しました。
モード 777 実際は 0 です 777 .その先頭の数字には setuid がありますと setgid ビット。
setuid/setgid であるほとんどのプログラムには、特定の特権で実行する必要があるため、そのビットが設定されています。今は壊れています。

/tmp を破りましたと /var/tmp ゼロになった先頭の 8 進数のもう 1 つの要素は、sticky bit です。 -- /tmp のファイルを保護するもの (そして /var/tmp ) を所有していない人によって削除されないようにします。
(残念ながら) rm -r /tmp/* を実行して「クリーンアップ」する、動作の悪いスクリプトがたくさんあります。、および /tmp に設定されたスティッキービットなしそのディレクトリ内のすべてのファイルに別れを告げることができます。
スクラッチファイルが消えると、よく書かれていないプログラムが本当に混乱する可能性があります...

あなたは /dev で大混乱を引き起こしました /proc および同様のファイルシステム
これは、/dev が存在する古い Unix システムではより大きな問題です。は実際のファイルシステムであり、そこに含まれるものは mknod で作成された特別なファイルです、許可の変更は再起動後も保持されるため、デバイスの許可が変更されているシステムでは、明らかなセキュリティリスク (誰もがすべての TTY を読み取ることができる) から、あまり目立たないカーネルパニックの潜在的な原因まで、重大な問題を引き起こす可能性があります。
Credit to @Tonny for pointing out this possibility

ソケットとパイプが破損するか、その他の問題が発生する可能性があります ソケットとパイプは完全に破損するか、誰でも書き込み可能になった結果、悪意のあるインジェクションにさらされる可能性があります。
Credit to @Tonny for pointing out this possibility

システム上のすべてのファイルを実行可能にしました
多くの人が . 持っています PATH で環境変数 (すべきではありません!) - コマンドのような便利な名前のファイルを誰でもドロップできるようになったため、これは不愉快な驚きを引き起こす可能性があります (たとえば make など)。または ls 、悪意のあるコードを実行するように仕向けます。
Credit to @RichHomolka for pointing out this possibility

一部のシステムでは chmod アクセス制御リスト (ACL) をリセットします
これは、すべてのアクセス許可を修正することに加えて、すべての ACL を再作成する必要が生じる可能性があることを意味します (コマンドが破壊的である実際の例です)。
Credit to @JamesYoungman for pointing out this possibility

すでに稼働しているシステムの部分は引き続き稼働しますか?おそらく、少なくともしばらくの間は。
しかし、次にプログラムを起動する必要があるとき、またはサービスを再起動する必要があるとき、または上記の #2 と #3 が醜い頭をもたげてくるので、あなたがいるボックスを再起動することは絶対に禁じられています.

解決策 2:

重要なことの 1 つは、ssh/sudo など、主要な構成ファイルのファイルシステムのアクセス許可をチェックするツールが多数あることです。アクセス許可が間違っている場合、これらのツールは失敗するように設計されています。これは、重大なセキュリティ上の問題を示しているためです。おそらく、ログインバイナリまたは PAM の何かに権限チェックがあるため、私の Debian テストシステムおよびおそらく他のシステムでは、ログインに失敗します。

したがって、実際にはシステムが破壊されているわけではありません。権限が間違っていると、多くのツールがすぐに失敗するように設計されているということです.

chmod 777 -R / を実行した後にシステムを再起動した場合起動し、明示的なアクセス許可チェックを持たないプロセスを開始できます。つまり、システムが実際に死んでいるわけではなく、仕様で多少使用できないだけです .