「chown -R root /」私はどのようにねじ込まれていますか?


8

railsアプリのパブリックフォルダーへのアクセス許可を変更しようとしているときに、誤ってコマンドchown -R root /を実行しました。これにより、/ディレクトリのすべてのフォルダへのアクセス許可が変更されたと思います。だから私の質問は、これがどれほど危険であるか、実際にはより良い質問だろう、とにかくこれを元に戻すことはあるのか?


3
これは自動的に元に戻すことはできません。もちろん、システムに大きな影響があります(さまざまなホームディレクトリを含みますが、これに限定されません)。最近のバックアップがお役に立てば幸いです。幸運を。
フレデリック

適切な権限とファイルの所有権についてシステムをチェックするプログラムがあります。tripwireは初期のものであると思います。複数のユーザーがいない場合は、そのようなツールからレポートや修正を取得するだけで状況を回復できる可能性があります。
minopret 2013

また、「悪化させるような方法で反応しない」および「最悪の事態を想定しない」に相当する以下のすばらしいアドバイスもお読みください。または、ジョークバージョンを使用した次の重要な一般的なトラブルシューティングの手順を覚えておいてください。緊急オペレーター:「パニックしないでください、あなたの友達は死んでいますか?」呼び出し元:BANG「はい、悲しいことに、彼は死んでいます。」
minopret 2013

ほとんどの場合、通常のシステムでは、所有者が誰であるかをファイルのグループから判別できるはずです。したがってfind、グループが適切ではないrootが所有するすべてのファイル、およびグループに一致するユーザーにすべてのファイルを共有します。失敗を記録し、個別に対処します。
agf 2013

そのコマンドをルートとして実行しましたか?(私はそうは思いません...)
アクセル

回答:


7

ここで問題を軽減する1つの方法(解決しないが、穴から抜け出すのに役立つ)は、同様のシステムでプロセスを実行して、ファイルの適切な所有権を収集することです。完全に一致する可能性は少し薄いと思いますが、o / sが同じレベルにあり、同様のパッケージがインストールされている場合は、幸運かもしれません。

ファイルのアクセス許可をファイルに収集したら、独自のシステムでプロセスを実行して、ファイルとperms / ownershipsを適切なものから読み取り、それらを自分のものに置き換えることができます。私はLinuxでこれを行う小さな自家製のアプリをいくつか持っています。

例えば

777*0*0*S*16*1334559119*1334532895*1361208513*/usr/lib32/*libgomp.so.1
644*0*0*F*67370*1359536382*1359374461*1359717843*/usr/lib32/*librt.a
644*0*0*F*59044*1334559119*1334532931*1355405098*/usr/lib32/*libgomp.so.1.0.0
644*0*0*F*1238*1359536382*1359374461*1359717843*/usr/lib32/*libBrokenLocale.a
777*0*0*S*17*1359536382*1359374460*1361208513*/usr/lib32/*libdl.so
644*0*0*F*905712*1334559116*1334533011*1355405098*/usr/lib32/*libstdc++.so.6.0.16
777*0*0*S*15*1333306601*1323929512*1361208513*/usr/lib32/*libbz2.so.1.0
777*0*0*S*24*1359536382*1359374460*1361208513*/usr/lib32/*libnss_files.so
644*0*0*F*1128*1359536382*1359374462*1359717843*/usr/lib32/*crt1.o

RWX * UID * GID *その他のもの*ディレクトリ*ファイル名


5

まず、コマンドがまだ実行されている場合は停止してください!

これですべてがrootに属し、それは非常に問題があります。

最新のバックアップから情報を復元する必要があります。

実行中のすべてのアプリケーションと、起動時にそれらを起動するユーザーを確認する前に、システムを再起動しないことも重要です。その場合、権限の問題により、一部が正常に起動しない可能性があります。

幸運を。


3

非常にではなく、かなり。

「非常に」というのは、コマンドが実際に通過した場合、セキュリティが台無しになるという意味です。これで、どのパスにどの所有者がいて、誰が何をすることが許可されるべきかがわかりません。

ある意味で「かなり」ではありません。実行したときにrootであり、コマンドが最後まで実行されましたか?あなたがそれをキャンセルした場合、あなたがそれを見るとすぐに、あなたは幸運であるかもしれません、そして、修理は低いかもしれません。もしあなたがrootでなければ、のようなことをしない限り、このコマンドはそれを実行できなかったはずですsudo ...

これに対する単一の救済策はありません。バックアップがある場合は、それに復元できます。バックアップの所有権を確認して適用する必要がある場合があります。ルートキット(たとえばrkhunter)チェッカーを使用している場合は、最も基本的な所有権のリストがあり、修正できる可能性があります。(可能性は低いです)。


2

少なくともFedoraでは、RPMコマンドにはオプション--setpermsとがあり--setugids、それらを使用して、システム所有のファイルのほとんどを修正できますrpm --setugids -a。各ユーザーのファイルを(ある程度)修正するには、ユーザーごとに行うことができますchown -R user /home/user。上記で修正されていない残り物がおそらくあるでしょう。特に、ある種のサーバー(web、ftp、その他)がある場合、それらは1つずつ処理する必要があります。

おそらく他のディストリビューションにも同様のメカニズムがあります。またはフル・リフレッシュを行います(それが何らかの形で破損していたように、すなわち、新たにすべてのものをインストールしてください。[OK]を、それがされた何らかの形で損傷を受けました。)

[はい、これもまた、疑いを持たないユーザーにEnterキーを押す前に各コマンドを注意深く検討し、ルートを慎重に使用することを教える、Unixのかなり残酷な方法です。独学してみてください。]


setuidそして、 setgid権限を手動で設定する必要があります。rpmそれらを復元しません。
jnas

1

OSXアップルを使用している場合、この問題を解決するためにディスクユーティリティ内に復元機能を提供します。Linuxディストリビューションを使用している場合は、すべての権限を手動でやり直す必要があると確信しています。どちらの場合も、手をたたいて、二度としないでください


Linuxでは、これから完全に回復できる可能性は低いでしょう。システムを動作させることができたとしても、不安定さやセキュリティの脆弱性のいずれかとして、後であなたに噛み付く可能性のある何かを見逃している可能性があります。バックアップからの復元または再構築のアプローチがおそらく必要だと思います。
クリスキュール2013

0

残念ながら、それを「元に戻す」方法はわかりませんが、おそらくシステムファイルをrootが所有しているままにして、$ HOME内のすべてのファイルを自分が所有するように復元することができます(そして、システム)。この時点で、$ HOMEディレクトリにない各ファイルのアクセス権や所有者を修正することができます。はい、これは苦痛ですが、簡単な修正はないと思います。それがとにかく私がすることです。


0

私はあなたが言うようにあなたはかなり「ねじ込み」だと思います。最良の方法(そして最も効率的な方法)は、重要なアイテムを適切なバックアップから再インストールして復元することです。申し訳ありませんが、これは通常、ハッピーエンドですぐに修正できる状況ではありません。幸運を!

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.