☰

ログインセッションを使用して別のユーザーとしてSystemdサービスを実行する

tag-icon • tag-icon systemd services cgroups logind
ログインセッションを使用して別のユーザーとしてSystemdサービスを実行する

質問

/run/user/uid起動時にランダムユーザーとしてランダムサービスを実行し、そのユーザーとして明示的にログインせずに、このユーザー（特別なインクルードの下のすべての便利な機能）に対して作成されたログインセッションを使用できますか？

背景

根のないPodman + systemdサービスと連携するようにdocker-compose展開を変換しています。 Podmanに関するほとんどの内容を把握していますが、特にsystemdを介して実行するのが困難です。

以前の展開では、各サービスのユーザーアカウントを作成し、そのユーザーとして実行するようにコンテナを構成しました。これは、ファイルシステムの制御とメンテナンスの観点から非常に便利であり、実際に維持したい主な属性です。

そのために私は見つけたこれaskubuntuの問題により、ユーザーを自分のシステムタスクに直接含め、そのユーザーとして実行できました。完璧。

問題は次のとおりです。 Fedoraはcgroups v2に移行し、現在はsystemdによって処理されています。これが実際にこのタスクの最初の理由です。したがって、Podmanはデフォルトでログインセッションを確立するためにログインする必要があるsystemdと会話できる必要があります（私が理解している場合）。これリンクが正しいです。）私はシステムの専門家ではないので、質問があれば訂正してください。

私が見つけたユーザーセッションの待機に関する別の質問これは私が求めているのと似ていますが、不可能であることを示すようです。私の状況は大きく2つの点で異なります。

  • 待たせたくないどのセッション（たとえば、起動時に対話なしで実行する必要があります）
  • 私のソリューションは、サービスを開始および終了するための手動介入に耐えるのに十分強力でなければなりません。

したがって、上記のように、サービスアプリケーションがsystemd（または少なくともcgroups v2部分）に接続するのに十分なログイン環境を持つ特定のユーザーでsystemdサービスを実行できる方法を探しています。

最後に、以下は、systemdに接続する必要があるまで、期待どおりに機能するサービスの1つのサンプルsystemdユニットファイルです。また、ログインしたユーザーとして手動で実行すると、Podman呼び出しは完全に機能します。

[Unit]
Description=Emby Podman Container

[Service]
User=emby
Group=emby
Restart=on-failure
ExecStartPre=/usr/bin/rm -f /%t/%n-pid /home/emby/%n-cid
ExecStart=/usr/bin/podman run --conmon-pidfile /%t/%n-pid --cidfile /home/emby/%n-cid -d --name=emby --cgroup-manager=systemd -e TZ="$TZ" -p 8096:8096 -p 8920:8920 -v /opt/docker/storage/emby:/config -v /media/media/:/media emby/embyserver
ExecStop=/usr/bin/sh -c "/usr/bin/podman rm -f `cat /home/emby/%n-cid`"
KillMode=none
Type=forking
PIDFile=/%t/%n-pid

[Install]
WantedBy=multi-user.target

答え1

だから少しブレーンストーミングの終わりにはあまりエレガントではありませんが、思ったよりシンプルで効果的なソリューションを見つけました。本論に入り、機能単位ファイルを見てみましょう。

[Unit]
Description=Emby Podman Container
[email protected]
[email protected]

[Service]
User=emby
Group=media
Restart=on-failure
ExecStartPre=/usr/bin/rm -f /home/emby/%n-pid /home/emby/%n-cid
ExecStartPre=-/usr/bin/podman rm emby
ExecStart=/usr/bin/podman run --conmon-pidfile /home/emby/%n-pid --cidfile /home/emby/%n-cid \
          --name=emby --rm --cgroup-manager=systemd \
          -e TZ="$TZ" \
          -p 8096:8096 -p 8920:8920 \
          -v /opt/docker/storage/emby:/config \
          -v /media/media/:/media \
          emby/embyserver
ExecStop=/usr/bin/sh -c "/usr/bin/podman rm -f `cat /home/emby/%n-cid`"
KillMode=none
Type=forking
PIDFile=/home/emby/%n-pid

[Install]
WantedBy=multi-user.target

ここで重要な洞察は、systemdにユーザーセッション自体を管理させることです（他のタスクを実行するのではなく）。 Embyサービスが実際に開始される前にEmbyユーザーのユーザーセッションが完全に作成されるため、この構成ではBindsToおよびを使用することがAfter不可欠です。これにより、管理者（読み取り：自分）がセッションをアクティブにするためにすべてのユーザーにログインする必要がなくなり、より多くのサービスやユーザーが追加されたときに役立ちます。

設定に関するその他の便利な注意：

  • この-dフラグはstdoutを通して見ることができるようにpodmanから削除されましたjournalctl -fu emby _TRANSPORT=stdout。テストと検証に便利です。
  • ~によると[Eメール保護]マニュアルページ、ユーザーサービスは名前ではなくUIDでインスタンス化する必要があります（私のシステムではemby == 1012）。Execコマンド以外の項目で拡張を実行する方法が見つからなかったため、今はハードコードされています。掃除方法を知っている人がいれば聞きたいです。
  • PIDファイルは書き込めないので、ユーザーのホームディレクトリに移動しました/run（それは問題ありません）。

私が試した他のものいいえ働く：

  • から直接ユーザーサービスを開始しますExecPre。デバイスがユーザーとして実行されているため、そのユーザー（チキンと卵）に対してsystmdを起動できません。
  • ユーザーを自動的にログインします。注：これは次のようになります。できるうまくいきますが、完全にログインしているユーザーにはセキュリティ上のリスクがあります。
  • suを介してユーザーを変更します。 systemd 管理者は、su に対して多少悲観的な見方をしています。そしてそれを修正することを拒否しました。宗教的な議論はさておき、簡単な説明はうまくいきません。

追加参考資料：

編集する：

もちろん、この記事を投稿するとすぐに、私を次のページに導いた魔法の検索文字列を見つけました。記事これは私のアプローチを排除します。

簡潔にするために、上記のドキュメントではサービスをrootとして実行し、コンテナのrootユーザーを必要なシステムユーザーに使用--uidmap/マッピングすることに焦点を当てています。--gidmap

ただし、このソリューションはPodmanにのみ適用されるため、rootやPodman以外のプロセスがsystemdにアクセスする必要がある他のユーザーのために上記を残しておきます。

最後に私は考える攻撃者がコンテナランタイムを損傷しても、スコープはまだ権限のないユーザーに制限されるため、私のソリューションはより安全です。これは、他のユーザーサービスを実行している攻撃面が増加して相殺される可能性があるため、おそらく洗浄です。

関連情報