26

数秒前にこれを実行しました。なんとかできましたCtrl- C自分が始めたことに気づいたらすぐに。

これまでのところ、それが通過し始めた唯一のディレクトリは/binです。

私は他のことをするのが怖いです。これまでのところ、私はsuもう通常のユーザーとして使用できないことに気付きました。

幸いなことに、私はまだ別のルート端末を開いています。私は何をしますか？

— 意志
ソース

26

あなたがそこにownられたように聞こえます、バディ。

— ta.speot.is

4

これで、バックアップの重要性が理解できました。定期的にやってください。

— ジュリアーノ

少なくとも彼はルートからchmodしませんでした。それは全面的な災害です。少なくともルートからのrm -rfにより、より多くのディスク領域が提供され、システム全体の再インストールの準備ができます。chmodは、完全なシステム再インストール以外では回復が非常に困難な真の混乱を残します。草はフェンスの両側で茶色ですよね？

— Fiasco Labs

10

/ bin /内のほとんどすべてはroot：rootが所有する必要があるため、次を実行すると、これらのファイルの所有権を修正できます。

chown root:root -R /bin/

また、/ bin / suでsetuidビットが適切に設定されていることを確認することもできます。これは、次の方法で修正できます。

chmod 4755 /bin/su

— epic9x
ソース

1

Ubuntuでは、sudoで同じことを行うことが特に重要です。ルートパスワードがデフォルトで設定されているとは思わないのですか？ところで、実際にはルートシェルの代わりにsudoを使用することをお勧めします。sudoを入力するのにかかる0.5秒は、通常、トラックでのような間違いを防ぎます。ただ、rootのシェル内で作業をするミスに簡単です...

— ベルント・ハウグ

4

paste.ubuntu.com/362468は、Ubuntu 9.10デスクトップの「ls -l / bin」です。私はあなたとまったく同じファイルをインストールしていないかもしれませんが、少なくとも、どのファイルに特別な許可が必要かについての良いヒントが得られるはずです。

— アンドル

@Bernd：私はそれほど多くの管理作業をしていませんが、ルートとして実行するよりも愚かなことはあまりありません。ルートパスワードを二度と使用することはありません。（そして、いや、Ubuntuにはデフォルトのrootパスワードはありません。MacOSXにはないと思います。）

— David Thornley

@David：OS Xにはデフォルトのルートパスワードは絶対にありません。設定するのはほとんど間違いです（IMO）。ほとんどの場合、別のより良い方法があります。問題は、Macは最初から安全ではないということです。RK、Virii、Botnetのクライアント＆cを収益化するためのより大きなインストールベースがあれば、多くの「楽しい」ものになると期待しています。

— ベルント・ハウグ

36

Redhatユーザー：

chown 0:0 /bin/rpm && rpm -qa | xargs rpm --setugids

Debian / Ubuntuユーザー：

chown 0:0 /bin/*  /usr/bin/*
chown daemon:daemon /usr/bin/at
chown 0:utmp /usr/bin/screen
chmod 02755 /usr/bin/screen
chmod u+s /bin/fusermount /bin/mount /bin/su /bin/mount
chmod u+s /usr/bin/sudo /usr/bin/passwd
screen

画面の実行中に、これを少なくとも2回実行します。

dpkg --get-selections | awk '{ if ($2 == "install") print $1}' \
    | xargs apt-get install --reinstall --

有料非常にそれが間違った権限を持つ何かについて不平を言うならば、あなたは別の画面ウィンドウ上でそれを修正する必要があるため、出力に細心の注意を。

画面のクラッシュコース：

Control+A     - command key
Control+A a   - emit a control+A
Control+A n   - next "screen"
Control+A c   - create "screen"

Solarisユーザー：

あなたはめちゃくちゃです。

pkgchk -R / -f -a

すべての権限をリセットしますが、setuid-nessは引き続き破損します。バックアップまたは別のsolarisマシンを使用して、setuid / setgidスクリプトとファイルを探し、それらを手動で修正します。

バックアップに関する重要なこと

それらを取り戻すことではなく、それらを回復できることです。

他の人からバックアップを取るようにアドバイスされていますが、それらをテストする必要があることを付け加えます。unixishシステムを使用している場合、ファイルを定期的に別のマシンにダンプしてすべてが機能することを確認できない理由は何もありません。

— ジオカー
ソース

FreeBSDユーザー：この種の間違いを犯すことはありません;）

— einstiien

10

@einstiienうん、FreeBSDユーザーは直接rm -rfステージに行きます。

— 悲惨さ

@grawity：笑、いいもの。

— -einstiien

貧しいSolarisユーザー:(

— Mircea Chirea

3

影響を受けるバイナリのset-uidフラグも削除されている可能性があることに注意してください。これはchownのセキュリティ機能です。バイナリにset-uidフラグまたはset-gidフラグが設定されている他のシステムを確認し、バイナリにも同様に設定してください。

— テディ
ソース

3

RPMを使用してファイルのアクセス許可をリセットする詳細について説明するつもりでしたが、より多くの情報を備えたサイトを見つけました。また、Ubuntu / Debian（したがって、一般に.debs）はサポートしていません。

しかし、一般的にあなたが探しているオプションは次のようなものです：

rpm --setugids {packagename}

— 小屋
ソース

これは、タグで示されているように、ubuntuシステム上にあります。これは、rpmと.RPMの代わりにdpkgと.DEBが使用されることを意味します

— ケビンM

2

これがdebianシステムである場合、私はaptitudeですべてを再インストールします。

— ptman
ソース

0

作業中のバックアップはありますか？はいの場合、binフォルダーを復元します。

そうでない場合は、同じバージョンのubuntuをインストールした他のボックスとchown、作業中のインストールで見つけたものを見てください。

— キリスト教の
ソース

0

これを試してください：/ binディレクトリですべてのwww-dataを見つけます

# find /bin -user www-data

次に、www-dataを元のユーザーに戻します

# find /bin -user www-data -exec chown ORiginalUser {} \;

# then change www-data back to oringal group
# find /bin -group www-data -exec chgrp originaluser {} \;

— スクイルマン
ソース

0

すばらしい回答をありがとう、すべてが今修正されたようです。

/ bin / suは、一度4755にchmodされたら機能しました（chownがsuidビットを変更した理由がわかりません）

私は気づいていませんでしたが、/ homeディレクトリでも動作し始めましたが、それは簡単な修正でした（user：groupを各ディレクトリのユーザーに設定するだけです）