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


14

XDG_RUNTIME_DIRsystemctl --user働くために必要です。

systemdユーザーセッションを実行するために、ubuntuサーバー16.04をセットアップしました。さて、それらを管理しようとすると、sudo -u $user -iまたはを介してユーザーを変更するsu - $userと、環境がXDG_RUNTIME_DIR設定されず、動作しなくなることがわかりsystemctl --userました。ただし、sshそのユーザーに直接アクセスすると、正しく設定されます。

ドキュメントを正しく理解していればlibpam-systemd、ユーザーセッションの作成時に設定する必要があります。XDG_RUNTIME_DIRpoint(/run/users/$uid)を指定するディレクトリが存在するため、ユーザースライスは正しく開始されます。たとえば、.bash_profileでハードコードするのはためらいます。なぜなら、PAMがそれを処理する必要があるとき、それは(動作しているとしても)ハッキーだと思われるからです。

もちろん、in に追加XDG_RUNTIME_DIRすることもできますが、それはsudoingユーザーの環境を維持するだけで、それは私が望んでいるものではありません。私がしたいターゲットユーザーの環境を。env_keepsudoers

しかし、私が本当に不思議に思っているのは、どうしてセッションがで正しく設定されsshているのsuか、ではなく、またはであるのsudo -iか?

回答:


9

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-run machinectlドキュメントでの参照にもかかわらず、期待どおりに動作していないようでした。

現時点でSELinuxを有効にしている場合、一部のmachinectlコマンドは機能しません。これらの特定のコマンドは、を実行するまで機能しませんでしたsetenforce 0。しかし、私はmachinectlをSELinuxに望むように動作させるための回避策を試みている最中であるため、私のいじりがmachinectl shellタイムアウトなどの原因になる可能性があります。

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


言い換えれば、PAMは設計上セッションに設定さXDG_RUNTIME_DIRれませんsudoか?それから私はそれを設定すること~/.profileは私が思ったほどハッキーではなかったと思います。
mkaito

3
「デザイン」とは言いたくありません。デザインが何であるかを判断できないからです。もう一度sudoを調べると、少なくとも一部のビルド/ディストリビューションが十分な環境変数を保持していることがわかります。rootとして実行されるプログラムは、元のユーザーにパーミッションの問題を引き起こす可能性があります。ただし、これは、ターゲットユーザーに対応するXDG_RUNTIME_DIRを設定しない理由ではありません。
sourcejedi

1
関連するQ&Aはunix.stackexchange.com/questions/423632です。
JdeBP

3

しかし、私が本当に不思議に思っているのは、sshでセッションが正しくセットアップされ、suまたはsudo -iではないのはなぜですか?

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

申し訳ありませんが、「su」はユーザーIDを変更するためのツールであり、一時的に他のプロセスの認証情報はほとんどありません。これは、まったく新しいログインセッションを開くためのツールではありません。新しいログインセッションには、他のセッションからは何も継承されない、非常に明確に定義された初期設定がありますが、これは実際には「su」uid変更の場合ではありません。 MACコンテキスト、監査コンテキスト、cgroupコンテキスト、ネームスペースコンテキスト、スケジューリング、タイマー粒度などの方法

完全に新しいセッションが必要な場合は、「machinectl login」または「machinectl shell」などを使用します。これにより、実際に完全にクリーンで独立したデタッチ環境が得られます。

ログインしたセッションはほとんど監査セッションの概念にバインドされ、監査セッションは「su」の影響を受けません。実際、それらは「封印」されるように定義されています。つまり、その子も同様です。つまり、新しいセッションを取得する唯一の方法は、PID 1(または同様のもの)からセッションの一部ではないものを分岐することです。

または、別の言い方をすれば、「su」を介して呼び出すものは「loginctl」でうまく表示されますが、元のログインの元のセッションの一部のままです。それを確認するには、元のセッションのIDで「loginctl status」を呼び出します(echo $ XDG_SESSION_IDで確認できます)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.