1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

本番運用しているサーバーでうっかり「chown root:root -R /」 してsuコマンドが死んだが、なんとか復活できた話

Last updated at Posted at 2019-12-19

前文

巷で
本番環境でやらかしちゃった人 Advent Calendar 2019
こちらのアドベントカレンダーが流行っていると聞いたので、私もうっかりやらかしたこと、反省点、そしてそこからサーバーを復帰させるまでの話を書こうと思います。

なお、この物語は実話のため少しteratailを検索すると事例が見つかると思いますので先に晒します。
CentOS6 chown root:root / したらsuが使えなくなった
当時の私の焦りなどが出ているかと思います。当時答えてくださったかた(すでに退会されているようですが…)本当にありがとうございます。

事件が起きるまでの概要

  1. すでに開発者の退社した本番運用されているシステムの入っている仮想サーバーに、apacheのバーチャルホストを追加してシステムを新しく建てることになった。
  • やってみたが、どうもパーミッション関係で上手くいかない。
  • 「あ、アップロード時にファイルが全部root権限になっちゃってる!じゃあこのディレクトリまるごとapacheの持ち物にしたら動くよね!」
  • # chown apache:apache -R / ←ドットの付け忘れタイポする。
  • ルートディレクトリが丸ごとapacheの持ち物に!?!? とりあえずrootに戻してもう一回apache権限を正しい範囲につけなおそ!
  • # chown root:root -R /
  • ほかにも ls -lの力を借りてmysqlやapache、/devや/homeの中身等は一通り他の同時期に借りたサーバーと突き合わせて権限修正。
  • とりあえずWebサーバーは見えたぞ!解決だな!とexitでrootアカウント及びapacheアカウントを抜ける。
  • 「解決!やったあ!もう一度サーバーに入って改めて見直そう!」
  • 「あれ? su -が効かないぞ・・・?」

事件の流れを追えばわかります。**この事件を起こした人はアホです。**まあ私なんですが。

サーバーの状況を確認

teratailのページを見ればわかるのですが、回答者がこう答えています。

可能であれば新規に環境を構築し、必要なファイルのみ移すといった対応がよいかと思います。

**私もそう思います。**しかし、このサーバーにはその時点では「私がソースコードを所持していない、管理者が退職したシステム」が動いていました。
その上Webサーバーとしては表面上全く問題なく動いているため、現行で使ってる人は居ます……。問題が発生するまでは時間の問題ですが。

まずはsuの復活から

突然ですが、何故chown root:root -R /したらsuコマンドが動かなくなったのでしょうか?

それはsetuidというものがchownによる権限変更をすると強制的に外れてしまうからです。

ではこのsetuidというのは何でしょうか?

それについてはこのように説明されています。

プログラム実行時アカウントを一時的に変更することで一般ユーザが投入したコマンドの中で特殊な権限を必要とする処理の実行を可能にする機能である。
-- IPA ISEC 第7章 セキュアUnix/Linux プログラミングより

とのことです。この件で初めてその存在を知りました。

幸いにも仮想サーバーだったため、サーバーそのものの提供されている機能を利用してsuは使えなくてもroot権限でコンソールに入ることは出来ました。
(また、エラー文から検索をかけ、sudoコマンドを復帰させることは成功しました)
そして/binに入ってls -lをしてみたところ、出るわ出るわ、大量のuidのセットされていない、本来ならばセットされているはずのアプリケーションを発見しました。

ここまで原因を絞り込んだら大丈夫です、setuidをすればいいのです。
# chmod u+s /bin/su
ついにsuが復帰しました!

すべては力業

ここまで解決したところで一つの欲が頭をもたげます。
「もしかして、二つのサーバーの状態を突き合わせたら、全部setuidまたはsetgidでなんとかなるんじゃないか?」
「特殊なアプリケーションは導入していないのは知っているし、ログ等もしっかりともう一つのサーバーと見比べてchownしていったら治るんじゃないのか?」

結論から言いますとやりましたそしてわりとなんとかなりましたただし丸一日かかりましたその上今でもたまにそれ由来のエラーが出ます
多分素直にサーバー移転したほうがかかった時間は短かったと思います・・・半分以下くらい・・・。

反省

まずそもそも仮想サーバーならば「問題が起きたら崩して作り直す」を鉄則としましょう。
世の中chown root:root -R /なんてやるアホ、そしてそこから継続して動かそうとするアホは滅多にいないため、想定外・調べても出ないエラーがいっぱい出ます。
やらかした人が社内に私一人のため原因がわかりやすく問題が大きくなりづらいですが、これが複数人重なったら大事件です。

そもそもタイポしない。そしてタイポ内容を送信しないようにする。
**完全にタイポをなくすのは不可能です。**せめてコマンドを入力する際はダブルチェック、指差し確認、コマンドそのものを別の場所に保存して確認を行いましょう。入力して即エンターなんて以ての外です。

chown apache:apache -R /の段階で立ち止まる。
そもそも詳しい人、やらかしたことがある人は気が付くと思います。
chown apache:apache -R /だけなら処理は途中で止まっているハズなのです。
つまりここの一番の失敗はapache権限になったroot画面を見て焦って chown root:root -R /したことなのです。
人間焦って進めようとせず、ちゃんと一呼吸置くことが必要かと思います。たいてい悪いことが起きます

おわり

以上、私の本番環境でやらかしたことでした。
みなさんもchownコマンドを使うときは、うっかりやってしまわないようにしっかり注意して行いましょう。
お疲れ様でした!

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?