☰

ユーザーはなぜグラフィカル アプリケーションを起動するために通常の sudo を使用してはいけないのでしょうか?

tag-icon • tag-icon sudo gui gksu
ユーザーはなぜグラフィカル アプリケーションを起動するために通常の sudo を使用してはいけないのでしょうか?

もう読んだコミュニティ「RootSudo」ドキュメントそして私はこの行に興味があります:

あなたがすべき一度もない通常の sudo を使用して、グラフィカル アプリケーションを Root として起動します。

なぜですか? 違いは何ですか? 私は普通のデスクトップユーザーなので、簡単な説明をお願いします。

答え1

Ubuntu 19.10以降では、その記事（そしてこの回答では）もはや適用されません。WinEunuuchs2Unix の回答同様にこの質問。

グラフィカルアプリケーションでは、設定やその他のユーザー固有のデータを、ユーザーのコンピュータ内に書き込まれた構成ファイルに保存することがよくあります。ホームフォルダアプリケーションがユーザーのホームフォルダとして何を使用するかを決定するために使用する主なメカニズムは、HOME 環境変数（ を使って自分で調べることもできますecho $HOME）。

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

sudoこれが、グラフィカルアプリケーションを、直接ではなくグラフィカルフロントエンドで実行する必要がある主な理由ですsudo。Ubuntuとその派生のほとんど（XubuntuとLubuntuを含む）では、標準のグラフィカルフロントエンドはgksu/gksudoKubuntuではkdesudo（それはデスクトップ環境使用されています。）

もし、あんたが欲しいsudoのようなグラフィカルアプリケーションを直接実行するには、gedit次のコマンドを実行します。

sudo -H gedit

フラグ-Hは、sudoのHOMEホームrootフォルダ（/root）。

それでも所有権は自動的に処理されません.Xauthorityそれを一時フォルダにコピーすることで（これはグラフィカルsudoフロントエンドが処理するもう 1 つのことです）。ただし、まれに に.Xauthorityアクセスできない場合は、アクセスできないというエラーが表示されます。その場合は、自動的に再生成されるので、 を削除することで問題を解決できます ( sudo rm ~/.Xauthority)。したがって、 の所有権と権限を保護することは、.Xauthority構成ファイルの所有権と権限を保護することほど重要ではありません。

root所有とは対照的に.Xauthority、設定ファイルが として所有されるとroot、問題が何であるかが必ずしも明らかではありません（グラフィカルプログラムは実行されてもうまく動作せず、役に立つエラーをコンソールに出力するため）。そして、特に次のような場合、修正が面倒になることがあります。ホームディレクトリ内の1つ以上のファイルを自分以外の誰かに所有させたい場合chown(すべてのファイルを自分自身に再帰的に戻すだけでは修正できないためです)。

したがって、sudo（少なくとも-H）なしではグラフィカルアプリケーションを実行するために使用すべきではない。ない限りアプリの内部動作に精通しており、アプリが構成ファイルを書き込もうとしないことを確実に知っています。

答え2

簡単に言えば：

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

それを読んでここまた、おそらく重複している「gksudo nautilus」と「sudo nautilus」の違いは何ですか?

答え3

Ubuntu 19.10 アップデート

現在ウブントゥ 19.10と入力すると、sudo some_commandと入力するのと同じ効果が得られますsudo -H some_command。つまり、変更された設定ファイルのディレクトリは、ディレクトリ(別名)/rootではなく、ディレクトリの下に置かれます。/home/regular_userID$HOME

このため、この Q&A 全体は、Ubuntu 19.10 以降のユーザーにとっては、ほとんど意味をなさないものになります。

ディストリビューションでsudo動作しているかどうかを確認するには、次の短いテストを試してください。sudo -H

$ sudo printenv | grep HOME
HOME=/home/rick

$ sudo -H printenv | grep HOME
HOME=/root

ご覧のとおり、sudo上記は実行されないsudo -Hため、プレーンを使用するとsudoユーザー構成ファイルに悪影響を与える可能性があります。

gksu nautilus、gksu geditまたはの代わりとして、アドオンsudo -H geditを使用することもできますnautilus-admin。これにより、ファイルやディレクトリを参照できます。ノーチラスその後、ルート (管理者) として開きます。

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

sudo apt install nautilus-admin

これで、Nautilus にログインすると、管理者として編集するための追加オプションが表示されます。

ノーチラス管理者.gif

geditルートでは設定が許可されないため

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

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

  • 通話方法sgedit filename1 filename2 ...
  • タブ ストップ、フォント、行折り返しなどのユーザーの gedit 設定を取得します。
  • sudo -Hルート権限を取得しながらファイルの所有権を保持するために昇格します。
  • sudo前回のタイムアウト時にパスワードを要求します。
  • sudoのgedit設定を取得します
  • ユーザーとsudo gedit設定の違いを比較します
  • 相違点のみに対して gsettings set を実行します (174 個の set コマンドが 12 個以下に減ります。次回の実行時には、おそらく 1 つか 2 つの変更のみが行われますが、変更がない場合もよくあります。
  • geditターミナルプロンプトがすぐに再表示されるように、バックグラウンド タスクとして呼び出します。

関連情報