sudoとsuを介して実行する場合、PATH変数が異なるのはなぜですか？

私のfedora VMで、ユーザーアカウントで実行している場合/usr/local/bin、次のパスにあります。

[justin@justin-fedora12 ~]$ env | grep PATH
 PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin

そして同様に実行するときsu：

[justin@justin-fedora12 ~]$ su -
Password: 
[root@justin-fedora12 justin]# env | grep PATH
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin

ただし、を介して実行する場合sudo、このディレクトリはパスに含まれません。

[root@justin-fedora12 justin]# exit
[justin@justin-fedora12 ~]$ sudo bash
[root@justin-fedora12 ~]# env | grep PATH
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/sbin:/bin:/usr/sbin:/usr/bin

経由で実行するとパスが異なるのはなぜsudoですか？

を見てください/etc/sudoers。Fedora（およびRHEL、Ubuntuなど）のデフォルトファイルには次の行が含まれています。

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

これにより、sudoでバイナリを実行するときにパスがクリーンになります。これはこの質問で指摘された懸念のいくつかから守るのを助けます。あなたが持っていない場合にも便利です/sbinし、/usr/sbinあなた自身のパスに。

このコマンドsu -は、ルートユーザープロファイルを実行し、パスなどを含むそのユーザーの環境を引き継ぎますsudo。

そのようsudoに動作したい場合は、ユーザーのプロファイルを実行するsu -オプションsudo -i [commandを使用します

そのようsu -に動作したい場合sudoは、ハイフンを使用しないでください-を使用してくださいsu [command]

を実行すると、理由を確認できます（異なる）sudo sudo -V。

たとえば、Linuxでは次を実行します。

$ sudo sudo -V | grep PATH
Value to override user's $PATH with: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

^{注：macOS / BSDでは、次を実行しますsudo sudo -V。}

上記のリストは、一部のLinuxディストリビューションのデフォルトのセキュリティポリシープラグインにより制限されています。

これについては、man sudoers次でさらに説明します。

secure_pathオプションが設定されている場合、その値はPATH環境変数に使用されます。

secure_path-sudoから実行されるすべてのコマンドに使用されるパス。sudoを実行している人々が健全なPATH環境変数を持っていると信用していない場合、これを使用することができます。

もう1つの用途は、「ルートパス」を「ユーザーパス」とは別にしたい場合です。exempt_groupオプションで指定されたグループのユーザーは、の影響を受けませんsecure_path。このオプションはデフォルトでは設定されていません。

その場合はsudo visudo、構成ファイルを実行および編集し、secure_path（で区切られた追加のパスを:追加する）を変更するか、ユーザーを追加するexempt_group（secure_pathオプションの影響を受けないようにする）ことで変更できます。

または、ユーザーのPATH一時を渡すために、次を実行できます。

sudo env PATH="$PATH" my_command

次の方法で確認できます。

sudo env PATH="$PATH" env | grep ^PATH

参照：作るためにどのようにsudo保存しますか$PATH？

環境がに対して異なる可能性がある他の理由は、ファイルでオプションを有効にするsudoことができるためです。これにより、新しい最小限の環境でコマンドが実行されます。env_resetsudoers

そのため、ユーザーの環境変数を保持するenv_keepためのオプション（セキュリティ上の理由で推奨されません）を使用できます。

Defaults        env_reset
Defaults        env_keep += "PATH PYTHONPATH"

ほとんどのLinuxでは、パッケージ管理を介してプログラムをインストールし、定期的に更新を取得します。パッケージ管理を回避する何かをインストールすると、/ usr / local / bin（または、... / sbin、または/ optなど）にインストールされ、定期的な更新は取得されません。

したがって、プログラムはそれほど安全であるとは見なされておらず、デフォルトでルートPATHに配置されていません。

私は自分でこれを試してみましたが、あなたが見ている振る舞いは見ませんでした-私のパスは同じままなので、多分あなたのsudo設定は異なっています。チェックman sudoersすると、secure_pathどのリセットと呼ばれるオプションがあることがわかりますPATH-このオプションは有効になっているようです。

あなたが使用している場合なのでsudo bash、bashログインシェルとして機能していないことはありません。で再試行するとsudo bash -l、と同じ結果が表示されsu -ます。

でそれが正しい場合は、差額PATHの設定ファイルにある：/etc/profile、~/.bash_profile、~/.bash_login、~/.profileログインシェルのために（そのために）実行され、しばらくは~/.bashrc非ログイン対話型シェルのために実行されます。

昔の質問は知っていますが、まさにこの問題を調査していたので、今ここで偶然見つけました。

何らかの理由で/usr/local/binを介してルートになったときのみPATHにありましたsudo su -。使用sudo -iするときはありませんでした。もちろん、/ etc / sudoersに追加できることはわかっていますが、それでもが既にそこにある理由を説明できませんでしたsu -。PATHのこの部分はどこから来たのですか？

多くのgrepを行い、検索した後、私は答えを見つけました：

'/ usr / local / bin'を含むデフォルトのパスは、実際にはsu（1）にハードコーディングされています。

したがって、この要素を選択的に追加するのに、PAMの構成、プロファイル、bashrcなどは一切関与しませんでした。su引き継がれたとき、それは常にすでにそこにあった。そして、sudoまったく起動せずsu、独自の構成を使用するため、後に欠落していましたsudo -i

これはRHEL6とRHEL7に当てはまることがわかりました。他のバージョンやディストリビューションをチェックしませんでした。