web-dev-qa-db-ja.com

ユーザーが通常のSudoを使用してグラフィカルアプリケーションを起動しないのはなぜですか?

コミュニティ「RootSudo」ドキュメント を読んで、この行に興味があります:

グラフィカルアプリケーションをルートとして起動するには、通常のSudoをnever使用する必要があります。

どうして?違いはなんですか?私は普通のデスクトップユーザーなので、簡単な説明を入力してください。

112
Nur

グラフィカルアプリケーションは、多くの場合、ユーザーの ホームフォルダー 内に記述された構成ファイルに設定やその他のユーザー固有のデータを保存します。ユーザーのホームフォルダーとして使用するものを決定するためにアプリケーションが使用する主なメカニズムは、HOME環境変数 です。 (echo $HOMEで自分で調べることができます)。

gedit (グラフィカルテキストエディター)を root として実行しているとします。 Sudo geditを実行すると、プログラムがas HOMEを実行している場合でも、rootyourホームディレクトリを指し続けます。その結果、geditは、構成ファイルas rootをホームディレクトリに書き込みます。これは 場合によっては結果として 設定ファイル内でowned by rootであり、したがって アクセスできない (後でrootとしてではなく自分でプログラムを実行するとき)。これは主に、アプリケーションが新しい構成ファイルを作成する必要がある場合に発生します。新しく作成されたファイルは、デフォルトでは、それらを作成したユーザー(この場合、あなたではなくroot)が所有します。

それが、まっすぐなSudoではなくグラフィカルなSudoフロントエンドでグラフィカルアプリケーションを実行する必要がある主な理由です。 Ubuntuおよびその派生物のほとんど(XubuntuおよびLubuntuを含む)では、標準のグラフィカルフロントエンドは gksu/gksudo です。 Kubuntuでは、 kdesudo です。 (使用されている デスクトップ環境 に依存します。)

wantを使用してSudoを直接使用し、geditなどのグラフィカルアプリケーションを実行する場合、次を実行できます。

Sudo -H gedit

-Hフラグは、SudoHOMEのホームフォルダー( /root )を指すようにrootを設定します。

.Xauthority をtempフォルダーにコピーしても、所有権は自動的に処理されません(これはグラフィカルなSudoフロントエンドが面倒を見てくれることです)。しかし、.Xauthorityにアクセスできないというまれなイベントでは、エラーがあることを示すエラーが表示されます。その後、自動的に再生成されるため、問題を削除して修正できます(Sudo rm ~/.Xauthority)。したがって、.Xauthorityの所有権と許可を保護することは、構成ファイルの所有権と許可を保護することほど重要ではありません。

rootが所有する.Xauthorityとは対照的に、構成ファイルがrootとして所有されるようになると、問題が何であるかが必ずしも明確ではありません(グラフィカルプログラムが頻繁に実行されますが、非常にうまく機能せず、コンソールに有用なエラーを出力するため)。そして、それは修正するのに大きな手間がかかる場合があります。特にホームディレクトリ内の1つ以上のファイルを自分以外の誰かが所有したい場合(修正できないためです)すべてのファイルを再帰的にchowningして、自分自身に戻します)。

したがって、Sudo(少なくとも-Hなし)を使用してグラフィカルアプリケーションを実行しないでくださいnlessアプリの内部動作に精通しており、設定ファイルを書き込もうとしないことを確認してください。

127
Eliah Kagan

簡単に言えば:

これにより、ホームディレクトリ内のファイルがルートによって所有されるのを防ぎます。

読んでください こちら 。また、おそらく 「gksudo nautilus」と「Sudo nautilus」の違いは何ですか?

25
carnendil

gksu nautilusおよびgksu geditの代わりに、nautilus-adminアドオンを使用することもできます。 Nautilusでファイルとディレクトリを参照し、それらをルート(管理者)として開くことができます。

インストールは簡単です。

Sudo apt install nautilus-admin

これで、nautilusを使用しているときに、管理者として編集するための追加オプションがあります。

nautilus admin.gif


ルートとしてのgeditは設定を許可しません

geditをrootとして実行すると、タブストップの通常ユーザーとして設定した設定を使用したり、タブをスペース、フォント名、フォントサイズ、行の折り返しなどに変換することはできません。

これを解決するために、ユーザー設定を継承してルートに適用するスクリプトsgeditを作成しました: ルートgeditをユーザーgeditの設定と同期するにはどうすればよいですか?

  • sgedit filename1 filename2 ...を使用して呼び出します
  • タブストップ、フォント、改行などのユーザーのgedit設定を取得します。
  • Sudo -Hに昇格して、ルート権限を取得しながらファイルの所有権を保持します。
  • 最後のSudoがタイムアウトした場合にパスワードを要求します。
  • 須藤のgedit設定を取得します
  • ユーザー設定とSudo gedit設定の違いを比較します
  • 差分のみに設定されたgsettingsを実行します(174個のsetコマンドを1ダース以下に減らします。次回はおそらく1つまたは2つの変更のみを実行しますが、多くの場合変更はありません。
  • ターミナルプロンプトがすぐに再表示されるように、バックグラウンドタスクとしてgeditを呼び出します。
5