Thorsten Kukuk, lider grupy rozwoju technologii przyszłości w SUSE (zespół Future Technology, rozwija openSUSE MicroOS i SLE Micro), który wcześniej przez 10 lat kierował projektem SUSE LINUX Enterprise Server, zasugerował pozbycie się pliku /var/run/utmp w dystrybucjach, aby w pełni rozwiązać problem 2038 w Glibc. Proponuje się konwersję wszystkich aplikacji korzystających z utmp, wtmp i lastlog w celu uzyskania listy użytkowników za pomocą systemd-logind.
19 stycznia 2038 roku nastąpi przepełnienie epokowych liczników czasu określonych przez 32-bitowy typ time_t. Glibc, pomimo wprowadzenia 64-bitowego typu time_t, w niektórych przypadkach nadal używa 32-bitowego typu time_t na platformach 64-bitowych, aby zachować kompatybilność z 32-bitowymi aplikacjami przestrzeni użytkownika. Jednym z takich przypadków jest plik /var/run/utmp, w którym przechowywane są dane o użytkownikach aktualnie zalogowanych do systemu. Pole czasu w utmp jest określone przy użyciu 32-bitowej wartości time_t.
Samo zastąpienie pola czasu w utmp z 32-bitowego na 64-bitowy nie będzie działać, ponieważ doprowadzi to do zmiany w ABI Glibc (typ zmieni się w funkcjach takich jak login(), getutid() i utmpname ()) i zerwanie kompatybilności z aplikacjami korzystającymi z utmp, w tym w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, menedżery wyświetlania xterm, emacs, openssh, qemu, samba, rsyslog itp. Ze względu na mnogość możliwych pułapek i złożoność pomysł zastąpienia typu time_t w utmp został odrzucony przez twórców Glibc. Z tego samego powodu odrzucono możliwość wykorzystania dostępnej wolnej przestrzeni w strukturze utmp w celu dodania dodatkowego 64-bitowego pola czasu.
Dodatkowo zmiana typu bit głębokość w utmp nie rozwiązuje innych istniejących problemów, których również chciałbym się pozbyć. Na przykład zapis do utmp wymaga specjalnych uprawnień, co wymaga przyznania procesom dodatkowych uprawnień. Kolejnym problemem jest to, że architektura utmp umożliwia lokalnym użytkownikom przeprowadzanie ataków DoS, co prowadzi do zakłóceń w działaniu usługi utmp poprzez manipulację blokadami plików, przez co nie można mieć pewności, że zawartość utmp odzwierciedla rzeczywisty stan w systemie. Proponowano użycie dodatkowego procesu w tle do obsługi dostępu do utmp, jednak do takich zadań istnieje już proces systemd-login i uruchamianie innego wyspecjalizowanego procesu nie jest wskazane (aplikacje będą musiały przesyłać dane do dwóch procedur obsługi jednocześnie).
Jednocześnie, nawet przy rozwiązywaniu problemu ataków DoS, zawartość utmp pozostaje jedynie informacyjna i nie gwarantuje odzwierciedlenia rzeczywistości. Na przykład różne emulatory i multipleksery terminali różnie odzwierciedlają swój stan - uruchomienie pięciu terminali GNOME spowoduje, że jeden użytkownik zostanie odzwierciedlony w utmp, a uruchomienie pięciu terminali konsolowych lub xterm w KDE spowoduje sześć. Zachowanie screen i tmux jest podobnie różne: w pierwszym przypadku każda sesja jest liczona jako oddzielny użytkownik, a w drugim tylko jeden użytkownik jest uwzględniany we wszystkich sesjach.
W rezultacie jako najprostsze rozwiązanie proponuje się przeniesienie wszystkich aplikacji do korzystania z już istniejącej alternatywnej usługi systemd-logind i w przypadku braku aktualnych programów uzyskujących dostęp do utmp, zatrzymanie nagrywania do utmp. W celu zastąpienia wtmp proponuje się przygotowanie interfejsów oprogramowania do zapisywania i odczytywania informacji o użytkownikach za pomocą systemd-journald. Baza kodu następnej wersji systemd 254 zawiera już niezbędną funkcjonalność do dostarczania danych zastępczych utmp poprzez libsystemd przy użyciu API sd-login.h lub poprzez DBUS.
Źródło: opennet.ru