SUSE 未來技術團隊（Future Technology Team，開發 openSUSE MicroOS 和 SLE Micro）的負責人 Thorsten Kukuk 曾領導 SUSE LINUX Enterprise Server 項目長達 10 年，他建議擺脫 /var/run/utmp 文件完全解決 Glibc 中的 Y2038 問題的發行版。 建議將所有使用 utmp、wtmp 和 lastlog 的應用程序遷移到使用 systemd-logind 獲取用戶列表。
19 年 2038 月 32 日，64 位元 time_t 類型指定的紀元時間計數器將會溢位。在 Glibc 庫中，儘管引入了 32 位元的 time_t 類型，但為了保持與 64 位元使用者空間應用程式的兼容性，在 32 位元平台上某些情況下仍然繼續使用 32 位元的 time_t 類型。 /var/run/utmp 檔案就是這樣一個例子，它儲存了有關目前在系統中工作的使用者的資料。 utmp 中的時間欄位使用 XNUMX 位元 time_t 值指定。
簡單地將 utmp 中的時間欄位從 32 位元更改為 64 位元類型是行不通的，因為這會改變 Glibc ABI（login()、getutid() 和 utmpname() 等函數中的類型會發生變化）並破壞與使用 utmp 的應用程式的相容性，包括 who、who、uptime、login、suject、c>d、who、upup顯示管理器、emacs、openssh、qemu、samba、rsyslog 等。由於潛在的陷阱很多，而且替換 utmp 中 time_t 類型的位元深度的想法很複雜，因此被 Glibc 開發人員拒絕了。出於同樣的原因，使用 utmp 結構中的可用空間來添加額外的 64 位元時間欄位的選項被拒絕了。
此外，更改 utmp 中類型的位元深度並不能解決我們也想擺脫的其他現有問題。例如，寫入 utmp 需要特殊權限，這需要授予進程額外的特權。另一個問題是，utmp 架構允許本機使用者透過操縱檔案鎖來執行破壞 utmp 服務的 DoS 攻擊，因此無法確定 utmp 內容是否反映了系統的實際狀態。有人建議使用額外的後台進程來處理對 utmp 的訪問，但 systemd-logind 進程已經存在用於此類任務，因此不建議啟動另一個專門的進程（應用程式必須同時將資料傳輸到兩個處理程序）。
然而，即使在解決 DoS 攻擊問題時，utmp 的內容仍然只是資訊性的，並不能保證反映現實情況。例如，不同的終端模擬器和多工器以不同的方式反映其狀態 - 啟動五個 GNOME 終端將導致一個用戶反映在 utmp 中，而在 KDE 中啟動五個 konsole 或 xterm 終端將導致六個用戶反映。類似地，screen 和 tmux 的行為也不同：在第一種情況下，每個會話被視為一個單獨的用戶，而在第二種情況下，所有會話只反映一個用戶。
因此，最簡單的解決方案是將所有應用程式切換為使用現有的替代 systemd-logind 服務，並且在沒有更多相關程式存取 utmp 後停止寫入 utmp。為了取代 wtmp，建議使用 systemd-journald 準備用於寫入和讀取有關使用者資訊的軟體介面。下一個 systemd 254 程式碼庫已經包含透過 libsystemd 使用 sd-login.h API 或透過 DBUS 提供 utmp 替換資料所需的功能。
來源： opennet.ru
