systemd-journaldデフォルト構成では、SplitMode=uid各ユーザーに対して別々のログ（log）ファイルが作成され、ユーザーが読み取ることができます。
実行中のサービスを使用する場合、DynamicUser=これはサービスがDynamicUser=任意の古いサービスログを読み取ることができることを意味しますか？
それでは、完全に自分のログファイルではなくログファイルを読み取ることができる潜在的な問題（セキュリティ？）がありますか？
編集：システムにコアダンプを別々のファイルまたはログとして保存することを心配している人はいますか？ (システムコアダンプ)
DynamicUser=のブログ記事では、UIDの再利用の影響について議論するときにジャーナルに言及しません。
http://0pointer.net/blog/dynamic-users-with-systemd.html
システムユーザーを登録したパッケージがシステム（少なくともほとんどのディストリビューションでは）から削除されたときにシステムユーザーが通常解放されない理由が疑問に思うかもしれません。その理由は、ユーザー概念の関連属性によるものです（設計上の欠陥と呼びたい場合があります）。ユーザーIDはファイル（およびIPCオブジェクトなどの他のオブジェクト）に添付されています。特定のシステムユーザーとして実行されているサービスが特定の場所にファイルを生成した後にそのパッケージとユーザーをシャットダウンして削除すると、生成されたファイルは元のシステムユーザーによって割り当てられた番号ID（「UID」）に属し続けます。次のシステムユーザーが割り当てられ、IDリサイクルのために同じ数値IDが割り当てられると、そのファイルにもアクセスできます。 、それ以降は読んだり変更したりしないでください。したがって、割り当てはUIDのリサイクルを避ける傾向があります。つまり、システムユーザーは一度割り当てられた後、システムに永久に登録されます。
...
この問題を解決するために、次の2つの戦略を簡単に考えることができます。
サービスがファイル/ディレクトリまたはIPCオブジェクトを生成することを許可しません。
サービスの終了時に生成されたファイル/ディレクトリまたはIPCオブジェクトを自動的に削除します。
systemdでは両方の戦略を実装していますが、実行環境の他の部分について...
ベストアンサー1
セキュリティの問題はありません。 （systemd v239を確認しました）。
DynamicUser= で使用する UID 範囲のユーザーは、自分のシステムログまたはシステムコアダンプを読み取ることができません。 「システム」ユーザー（通常はUID < 1000）とnobody。
https://github.com/systemd/systemd/blob/v239/src/coredump/coredump.c#L157
if (uid_is_system(uid) || uid_is_dynamic(uid) || uid == UID_NOBODY)
return 0;
/* Make sure normal users can read (but not write or delete)
* their own coredumps */
https://github.com/systemd/systemd/blob/v239/src/journal/journald-server.c#L225
static bool uid_for_system_journal(uid_t uid) {
/* Returns true if the specified UID shall get its data stored in the system journal*/
return uid_is_system(uid) || uid_is_dynamic(uid) || uid == UID_NOBODY;
}