systemd DynamicUser= services vs journald splits

systemd-journald具有預設配置SplitMode=uid，為每個使用者創建單獨的日誌（日誌）文件，允許他們閱讀。

使用 執行服務時DynamicUser=，這是否意味著該服務可以讀取隨機舊DynamicUser=服務的日誌？

如果是這樣，是否存在潛在的問題（安全性？）能夠讀取不屬於您自己的日誌文件？

編輯：肯定有關於 systemd 保存為單獨文件或日誌中的 coredumps 的問題嗎？（系統核心轉儲）

---

DynamicUser= 的部落格文章在討論重用 UID 的影響時沒有提及期刊。

http://0pointer.net/blog/dynamic-users-with-systemd.html

您可能想知道為什麼系統使用者在從系統中解除安裝註冊它們的軟體包時通常不會被釋放（至少在大多數發行版上）。原因是使用者概念的一個相關屬性（您甚至可能想稱其為設計缺陷）：使用者 ID 對文件（以及其他對象，例如 IPC 對象）具有粘性。如果作為特定係統使用者執行的服務在某個位置創建文件，然後被終止並刪除其包和使用者，則創建的文件仍屬於系統使用者最初分配的數字 ID（“UID”）。當下一個系統使用者被分配並且——由於 ID 回收——碰巧被分配了相同的數字 ID，那麼它也將獲得對文件的訪問權限，這通常被認為是一個問題，鑑於該文件曾經屬於一個可能非常不同的服務，並且可能不應該被它之後的任何東西讀取或更改。因此，發行版傾向於避免 UID 回收，這意味著系統使用者在分配一次後會永遠在系統上註冊。

…

為了解決這個問題，很容易想到兩種策略：

1. 禁止服務創建任何文件/目錄或 IPC 對象
2. 自動刪除服務關閉時創建的文件/目錄或 IPC 對象。

在 systemd 中，我們實現了這兩種策略，但是針對執行環境的不同部分……

這不存在安全問題。（我簽入了 systemd v239）。

DynamicUser= 使用的 UID 範圍內的使用者無法讀取他們自己的 systemd 日誌或 systemd coredump。同樣的限制適用於“系統”使用者（通常 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;
}

引用自：https://unix.stackexchange.com/questions/429699