Ubuntuでフォルダーのアクセス許可をデフォルトにリセットする方法は?


19

最近コマンドを入力しました

sudo chmod 777 -R /

その後、いくつかのようなもの

sudo -i

正常に動作していません。だから私は、フォルダのアクセス許可を元の状態にリセットできる方法があるかどうか疑問に思っていますか?


Linuxが以前の許可設定を記憶しているとは思わない。新しいファイルを作成してみて、どの許可設定が取得されるかを確認してください。
thecoshman

ああ待って、あなたがそこで何をしたかわかります。これはおそらく再インストールの状況です。データをバックアップするだけで、インストールしたアプリケーションをメモしてください。楽しんで、10.4を試してみませんか!(これまでで最高の名前...そのラジオの意味は?)
thecoshman

私はあなたがその正確なことをしていない一人を見つけることを敢えてする:Dそれは非常にトリッキーな状況です。あなたはそれを修正し、jloviの答えを試すことができますが、時間と労力がかかり、イライラするでしょう。単に再インストールして、それをやり直してください。そして、何をしているのかわからない限り、sudo chmodを使用しないでください。
ジャックマイヤーズ14

回答:


17

この厄介な状況から戻ってくることは可能です。

問題について同じ種類のスクリプトを再度実行し(私が書いていたスクリプトのバグ)、それを解決しましたが、専門家の助けを求める必要があります。非常に注意してください!

まず、デュアルブートシステム(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:

  1. このための重要なことは、インストールディスクを使用しているバージョンと同期させるか、少なくとも現在のubuntuバージョンで動作させることです。
  2. 現在、このコマンドを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句の順序を入れ替える必要があるかもしれません。


ただ優秀な答え。私はUbuntuの質問
Private

私にとって完璧なソリューションです!

2

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)

debsumsは実際にパーミッションをチェックしますか?私は試してみましたがchmod a-x /bin/pingdebsums -cそのファイルは報告しませんでした。
reox

0

sudoとして実行するものを常に監視します。

このスレッドは、いくつかのアクセス許可を手動で設定し直すことができることを説明しており、そこにあるスクリプトがこれに役立ちますが、それでも大きな仕事です。むしろ、トレッドのヒントに従ってインストール済みパッケージ(マーキング)を保存し、OSを再インストールし、保存したパッケージマーキングを適用してアプリケーションを元に戻します。


0

私の知る限り、ファイル権限を修復するコマンドを提供するのはSystem VパッケージとRPMだけです。System V(Solaris)ではpkgchk、RPMではrpm --setpermsです。

残念ながら、そのようなコマンドはDebian / Ubuntuパッケージには存在しないようです-しかし、私はここで間違っているかもしれません。

しかし、これらのコマンドを使用しても、システムを正常な状態に戻すのは簡単な作業ではありません。システムを修復することで、システムに新しい害を簡単に引き起こす可能性があります。

ジョセフが言った以外に、あなたは最初のものではなく、あなたはそのようなコマンドを入力する最後のものではありません。しかし、Unixシステムでファイルのアクセス権を777に変更するという考えだけでは、この種のシステムをあまり経験していないことを強く示しています。この状況でできる最善の方法は、必要なもの(ホームディレクトリ、構成ファイル、メールファイル?)を再度バックアップし、新規インストールを試すことです。

また、破損したバックアップファイルを復元するときは、非常に注意する必要があります。

がんばろう!

PS:どんな問題を解決したいのかと思っていますか?


0

うわー、あなたはそれを殺した。死んだ!ログインして(有効にしたため)マシンをルートとして使用し、ルートのグループメンバーシップをユーザーに変更してください。私は以前に試したことがないが、一見の価値があるので、これはうまくいくかもしれないし、うまくいかないかもしれない。


0

chmod操作を元に戻すことはできません。少なくとも、以前の設定にロールバックするという意味ではありません。これは、この状況が必要とするものです。おそらく、各ファイルとディレクトリを元のモードに戻すことにより、操作取り消すことができます、それらはすべて同じではありません。元のモードを決定するのは難しい(他の回答で説明したように)。chmodchmod

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