sudo -iがターゲットユーザーにXDG_RUNTIME_DIRを設定しないのはなぜですか?

sudo -iがターゲットユーザーにXDG_RUNTIME_DIRを設定しないのはなぜですか?

XDG_RUNTIME_DIRsystemctl --user仕事に必要です。

システムユーザーセッションを実行するためにUbuntu Server 16.04を設定しました。これで、管理しようとしたときにsudo -u $user -iユーザーを転送または変更したときにsu - $user環境がXDG_RUNTIME_DIR設定されていないため、機能しないことがわかりましたsystemctl --user。ところでsshユーザーに直接行ってみると正しく設定されていますね。

ドキュメントを正しく理解したら、libpam-systemdユーザーセッションの作成時に設定する必要があります。ユーザーフラグメントXDG_RUNTIME_DIRが指す必要があるディレクトリ()が存在するため、ユーザーフラグメントが正しく開始されます/run/users/$uid。たとえば、私はこれをハードコーディングすることを躊躇します。.bash_profileなぜならそれは陳腐に見え(有効ですが)、pamがこれを処理しなければならないからです。

もちろん、追加することもできますが、XDG_RUNTIME_DIRそうenv_keepすればsudoerssudoingユーザーの環境だけが保存されるので、私は望むものではありません。欲しいターゲットユーザー環境。

しかし、私が本当に知りたいのは、or_set_session_properlyをssh使用する代わりにset_session_properlyを使用する理由です。susudo -i

答え1

私のFedora 25システムでこの問題を再現しました。

ソースコードで非常に疑わしい状況を見つけました。 https://github.com/systemd/systemd/blob/f97b34a/src/login/pam_systemd.c#L439 普通の気持ちで書いたようですが、sudoそうではありませんsudo -u non-root-user

machinectl shell --uid=non-root-userあなたの仕様に合わせて作業してください。

systemd-runmachinectlのドキュメントで参照されていますが、期待どおりに動作しないようです。

現在SELinuxを有効にしている場合、特定のmachinectlコマンドは機能せず、これらの特定のコマンドは有効になるまで機能しませんでしたsetenforce 0。しかし、私はSELinuxで動作したいので、machinectlが動作するようにする回避策を試しているので、タイムアウトの原因になる可能machinectl shell性があります。

編集:このコードは次の後に導入されたようです。この議論。明らかにsu -/sudo -i動作することができますが、誰も(まだ)それを実装していません。

関連コミットはhttps://cgit.freedesktop.org/systemd/systemd/commit/?id=baae0358f349870544884e405e82e4be7d8add9f

答え2

しかし、私が本当に知りたいのはなぜsshを使ってセッションを正しく設定しますが、suまたはsudo -iを使用しないのですか?

https://github.com/systemd/systemd/issues/7451#issuecomment-346787237

申し訳ありません。 「su」は、ユーザーの身元と他のプロセスの資格情報を一時的に変更するために使用されるツールです。まったく新しいログインセッションを開くツールではありません。新しいログインセッションには明確に定義された元の設定があり、他のセッションから何も継承しませんが、「su」uidの変更は実際には行いません。ほとんどの実行環境は、MAC コンテキストなど、実質的で明白ではない方法で継承されます。監査コンテキスト、cgroupコンテキスト、ネームスペースコンテキスト、予約、タイマー粒度...

まったく新しいセッションが必要な場合は、「machinectl login」や「machinectl shell」などを使用してください。これは、実際には、呼び出しから隠されたプロセス属性を持たない完全にクリーンで独立した、分離された環境を提供します。どこかから漏れています。

ログインセッションは主に監査セッションの概念に関連付けられており、監査セッションは「su」の影響を受けません。実際には「封印済み」と定義されます。つまり、プロセスがセッションに一度入ると、そのセッションと永久に一緒に保持されます。プロセスも同様です。つまり、新しいセッションを取得する唯一の方法は、セッションの一部ではなくPID 1(または同様のもの)から分岐することです。

つまり、「su」を介して呼び出された内容は「loginctl」にはよく表示されますが、最初にログインした元のセッションの一部として残ります。元のセッションIDで「loginctl status」を呼び出すことでこれを確認できます(echo $ XDG_SESSION_IDで確認できます)。

答え3

sudo -E bash正しく実行するとXDG_RUNTIME_DIR

答え4

それでも解決策が必要な場合は、sudo -ipamモジュールをインストールしてくださいXDG_RUNTIME_DIRPam_xdg

あなたのディストリビューションにこのパッケージがある可能性はほとんどないので、pam_xdgこのモジュールをインストールするには直接インストールする方法を理解する必要があります。私はGentooを使用しており、モジュールをインストールするebuildを作成しましたが、まだリリースしていません。なぜなら、私のオーバーレイに仕上げる必要がある開発コミットが多すぎるからです。この回答はアップロードされたら更新します。

pamモジュールを正しく取り付けたら、次の行を追加してください/etc/pam.d/sudo-i

session optional        pam_xdg.so

必要に応じてrequired代わりに指定してください。optional

このモジュールはデフォルトのXDG値を生成しようpam_systemd.soとしますmachinectl shell

関連情報