☰

以下を比較してください

tag-icon • tag-icon shell login
以下を比較してください

だからこの問題これは以前に要求されましたが、それに対する答えは環境変数の問題を解決しませんでした。pam-systemdすべての自動XDG環境変数が呼び出され、設定されるようにユーザーを完全に切り替える方法はありますか？

以下を比較してください

次のオプションは、まず電源がオフになっているコンピュータの電源を入れます。

オプション1ルートとしてログインします。シェルに次のように入力します。

su -l username
echo $XDG_RUNTIME_ENV

オプション2ユーザー名でログインしてください。シェルに次のように入力します。

echo $XDG_RUNTIME_ENV

違いがあることがわかります。/run/user/0使用されたユーザーが変更su（ユーザー切り替え）されているにもかかわらず、pam_systemd切り替え中にモジュールが呼び出されなかったため、オプション1は引き続き発生します。オプション2の収益率は/run/user/$(id -u)予想と一致しています。exit必要なユーザーとして再度ログインするように求められるまで、ログアウトを入力するだけです。別の方法がありますか？sudo代わりに使用してもsu役に立ちません。

実装されているecho "XDG_RUNTIME_DIR=$(id -u) >> .bash_profile"ように、これは正しいことですか？.bash_profilesu

答え1

答えは、モジュールが実行され、変数が設定されていることを確認するloginのではなく、単に使用することです。 Giacomoが指摘したように、1人のユーザーだけが（複数のユーザーが作成されたサブプロセスシナリオのように）その中でファイルを変更できることを確認してください。環境。supam_systemdsu

リスクは、以下を使用してsuシステムに視覚的に表示できます。systemd

使用su

root  -systemd
root    -login # calls pam_systemd and sets XDG_RUNTIME_DIR among others
user1     -bash
user1       -su
user2         -bash # user1 has access to spawned subprocesses?

使用login

root -systemd
root   -login # calls pam_systemd and sets XDG_RUNTIME_DIR among others
user2     -bash

子プロセスによってカプセル化されたユーザーは、によって登録されたことがないためloginctl登録されません。su/bashsystemd-logind.servicepam_systemd.mod

答え2

root/sudo アクセス権を持っていて、パスワードを知らないか変更せずに他のユーザーを完全に偽装する必要がある場合は、Linux ディストリビューションがそれをサポートするのに十分近代的である場合は、以下を使用する必要があります。

sudo machinectl shell --uid usernameGoesHere

これは基本的にセッションを作成し、$XDG_ユーザーの通常の環境（で始まる変数を含む）のログインシェルを提供するので、すべてがユーザーが正常にログインしたときと同じように見え、機能する必要があります。これは、ログイン資格情報なしで一般ユーザーログインのすべての側面を複製する私が見た注文よりも優れていますsu。sudo

言うまでもなく、システム管理者として、これはユーザーが直面する問題を解決したり、環境に応じて他のユーザーに代わって実行したりするのに役立ちますpodman。

関連情報