最近コマンドを入力しました
sudo chmod 777 -R /
その後、いくつかのようなもの
sudo -i
正常に動作していません。だから私は、フォルダのアクセス許可を元の状態にリセットできる方法があるかどうか疑問に思っていますか?
最近コマンドを入力しました
sudo chmod 777 -R /
その後、いくつかのようなもの
sudo -i
正常に動作していません。だから私は、フォルダのアクセス許可を元の状態にリセットできる方法があるかどうか疑問に思っていますか?
回答:
この厄介な状況から戻ってくることは可能です。
問題について同じ種類のスクリプトを再度実行し(私が書いていたスクリプトのバグ)、それを解決しましたが、専門家の助けを求める必要があります。非常に注意してください!
まず、デュアルブートシステム(Ubuntuと古いFedoraのインストール)があるため、私の状況は簡単に解決できましたが、CD / DVDまたはUSBキーからOSを実行しても同じことができるはずです。
MPOINT=/mount/ubuntu
まず、次のようにファイルシステムをマウントしました(マウントポイントの作成を忘れないでください)。
mount /dev/ubuntu/root $MPOINT
mount /dev/ubuntu/home $MPOINT/home
次に、実行中のシステムから乱雑なシステムにアクセス許可をコピーするために、次のコマンドを実行しました(私の問題はいくつかの重要なディレクトリにしかありませんでした)そしてそこに許可を得ました):
find /etc /usr /bin /sbin -exec stat --format "chmod %a \"${MPOINT}%n\"" {} \; > /tmp/restoreperms.sh
そして、restoreperms.shスクリプトを実行しました。
Ubuntuで再び起動することができました。
restoreperms.shの内容は次のようになります。
(...)
chmod 755 /mount/ubuntu//etc/ppp
chmod 755 /mount/ubuntu//etc/ppp/ipv6-up
chmod 2750 /mount/ubuntu//etc/ppp/peers
chmod 640 /mount/ubuntu//etc/ppp/peers/provider
chmod 755 /mount/ubuntu//etc/ppp/ipv6-up.d
chmod 777 /mount/ubuntu//etc/ppp/resolv.conf
(...)
私はそれをテストしませんでしたが、所有者と所有者グループでも機能する必要があります。何かのようなもの:
find /etc /usr /bin -exec stat --format 'chown %U:%G ${MPOINT}%n' {} \; > /tmp/restoreperms.sh^
(...)
chown root:root /mount/ubuntu//etc/obex-data-server/imaging_capabilities.xml
chown root:root /mount/ubuntu//etc/obex-data-server/capability.xml
chown root:dip /mount/ubuntu//etc/ppp
chown root:root /mount/ubuntu//etc/ppp/ipv6-up
chown root:dip /mount/ubuntu//etc/ppp/peers
chown root:dip /mount/ubuntu//etc/ppp/peers/provider
chown root:root /mount/ubuntu//etc/ppp/ipv6-up.d
chown root:root /mount/ubuntu//etc/ppp/resolv.conf
(...)
もちろん、UIDとGIDは両方のシステムで同じであることに注意する必要がありますが、システム関連のユーザーとグループの場合、これは問題になりません。
編集:
また、所有者を設定すると、SGIDおよびSUIDフラグが無効になり、奇妙な問題が発生します(たとえば、許可が4755でない限り、sudoを実行できません)。あなたは必要、とのみ権限を設定する必要がありAFTER所有者を設定します。所有者情報とともに完全なファイル許可情報を保存してください。
Rk:
現在、このコマンドをcronjobに入れて、その情報を保持するために毎日(場合によっては数週間)実行しています。次回はソリューションが簡単になりますが、もちろん、これが今あるので、二度と起こりません。;-) このようなもの:
0 12 * * * /usr/bin/find / -exec /usr/bin/stat --format="/bin/chmod %a %n" {} \; |/bin/bzip2 -c > /tmp/restore_chmod.$(/bin/date +%w).sh.bz2
0 13 * * * /usr/bin/find / -exec /usr/bin/stat --format="/bin/chown %U:%G %n" {} \; |/bin/bzip2 -c > /tmp/restore_chown.$(/bin/date +%w).sh.bz2
正しい(組み合わせた)コマンドは、次のようなものです。
`/usr/bin/find / -exec /usr/bin/stat --format="[ ! -L {} ] && /bin/chmod %a %n" {} \; -exec /usr/bin/stat --format="/bin/chown -h %U:%G %n" {} \; |/bin/bzip2 -c > /tmp/restore_fileperms.$(/bin/date +%w).sh.bz2`
ファイル名の括弧を考慮するために(ロケールなどで)追加の注意が必要になる場合があり、chownがchmodによって設定されたsetuidおよびsetgidビットをサイレントに設定解除する場合があることに注意してください。/ bin / suや/ usr / bin / sudoなどを壊す後者の場合、上記のexec句の順序を入れ替える必要があるかもしれません。
sudoをリカバリした後、またはブート時にリカバリモードを選択した後
ファイルの整合性と権限を検証するデブサムを使用して、システム全体を回復することができます。
manページから:
apt-get install --reinstall $(dpkg -S $(debsums -c) | cut -d : -f 1 | sort -u)
変更されたファイルでパッケージを再インストールします
または特定のパスに限定されます。例/usr
::
apt-get install --reinstall $(dpkg -S $(debsums -c | grep -e ^/usr ) | cut -d : -f 1 | sort -u)
または、複数のパスのセットに限定されます。例: /sbin /etc /var
apt-get install --reinstall $(dpkg -S $(debsums -c | grep -e ^/etc -e ^/sbin -e ^/var ) | cut -d : -f 1 | sort -u)
chmod a-x /bin/ping
、debsums -c
そのファイルは報告しませんでした。
私の知る限り、ファイル権限を修復するコマンドを提供するのはSystem VパッケージとRPMだけです。System V(Solaris)ではpkgchk、RPMではrpm --setpermsです。
残念ながら、そのようなコマンドはDebian / Ubuntuパッケージには存在しないようです-しかし、私はここで間違っているかもしれません。
しかし、これらのコマンドを使用しても、システムを正常な状態に戻すのは簡単な作業ではありません。システムを修復することで、システムに新しい害を簡単に引き起こす可能性があります。
ジョセフが言った以外に、あなたは最初のものではなく、あなたはそのようなコマンドを入力する最後のものではありません。しかし、Unixシステムでファイルのアクセス権を777に変更するという考えだけでは、この種のシステムをあまり経験していないことを強く示しています。この状況でできる最善の方法は、必要なもの(ホームディレクトリ、構成ファイル、メールファイル?)を再度バックアップし、新規インストールを試すことです。
また、破損したバックアップファイルを復元するときは、非常に注意する必要があります。
がんばろう!
PS:どんな問題を解決したいのかと思っていますか?