Thorsten Kukuk, lider zespołu ds. rozwoju technologii przyszłości w firmie SUSE, który rozwija openSUSE MicroOS i SLE Micro, a wcześniej przez 10 lat kierował projektem SUSE LINUX Enterprise Server, zaproponował usunięcie pliku /var/run/utmp w dystrybucjach, aby całkowicie rozwiązać problem roku 2038 w Glibc. Wszelkie aplikacje wykorzystujące utmp, wtmp i lastlog powinny przejść na pozyskiwanie listy użytkowników przy użyciu systemd-logind.
19 stycznia 2038 roku nastąpi przepełnienie liczników czasu epokowego, które są zadane przez 32-bitowy typ time_t. W bibliotece Glibc, mimo wdrożenia 64-bitowego typu time_t, aby zachować zgodność z aplikacjami 32-bitowymi, w niektórych przypadkach na platformach 64-bitowych nadal stosuje się 32-bitowy typ time_t. Jednym z takich przypadków jest plik /var/run/utmp, który przechowuje dane o użytkownikach aktualnie pracujących w systemie. Pole z czasem w utmp jest zadawane za pomocą 32-bitowej wartości time_t.
Nie można po prostu zamienić pola z czasem w utmp z 32-bitowego na 64-bitowy typ, ponieważ spowoduje to zmianę ABI Glibc (zmieni się typ w funkcjach takich jak login(), getutid() i utmpname()) oraz naruszenie zgodności z aplikacjami korzystającymi z utmp, w tym wśród nich w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, menedżery wyświetlaczy xterm, emacs, openssh, qemu, samba, rsyslog itp. Z powodu licznych możliwych pułapek i trudności koncepcja zamiany w utmp typu time_t została odrzucona przez programistów Glibc. Z tego samego powodu odrzucono wariant wykorzystania wolnej przestrzeni w strukturze utmp do dodania dodatkowego 64-bitowego pola czasowego.
Dodatkowo zmiana typów w utmp nie rozwiązuje innych istniejących problemów, których również chcielibyśmy się pozbyć. Na przykład, aby zapisać dane w utmp wymagane są specjalne prawa, co skutkuje koniecznością przyznawania procesom dodatkowych przywilejów. Innym problemem jest to, że architektura utmp pozwala lokalnym użytkownikom na przeprowadzanie ataków DoS, które mogą prowadzić do zakłóceń w działaniu usługi utmp poprzez manipulacje blokadami na pliku, przez co nie ma 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ń już istnieje proces systemd-logind, a uruchamianie jeszcze jednego wyspecjalizowanego procesu nie jest celowe (aplikacje musiałyby przesyłać dane jednocześnie do dwóch obsługiwaczy).
Jednak nawet po rozwiązaniu problemu z atakami DoS, zawartość utmp pozostaje jedynie informacyjna, nie gwarantując odzwierciedlenia prawdziwej rzeczywistości. Na przykład, różne emulatorzy i multiplexerzy terminali różnie przedstawiają swoje stany — uruchomienie pięciu terminali GNOME spowoduje odzwierciedlenie jednego użytkownika w utmp, podczas gdy uruchomienie pięciu terminali konsole lub xterm w KDE — sześciu. Podobnie różnią się zachowania screen i tmux; w pierwszym przypadku każda sesja jest liczona jako oddzielny użytkownik, podczas gdy w drugim odzwierciedlany jest tylko jeden użytkownik dla wszystkich sesji.
W rezultacie, jako najprostsze rozwiązanie proponuje się przeniesienie wszystkich aplikacji na korzystanie z już istniejącej alternatywy systemd-logind, a po zaprzestaniu pracy wszystkich aktualnych programów korzystających z utmp, zaprzestaną zapisywania w utmp. W celu zastąpienia wtmp proponuje się przygotowanie interfejsów programowych do zapisu i odczytu informacji o użytkownikach za pomocą systemd-journald. W kodzie bazowym kolejnej wersji systemd 254 już zawarto niezbędne funkcje do dostarczania danych zastępujących utmp poprzez libsystemd z wykorzystaniem API sd-login.h lub przez DBUS.
Źródło: opennet.ru
