Thorsten Kukuk, the leader of the Future Technology Team at SUSE, which develops openSUSE MicroOS and SLE Micro, and who previously led the SUSE LINUX Enterprise Server project for 10 years, suggested removing the file /var/run/utmp in distributions to completely solve the year 2038 problem in Glibc. It is recommended that all applications using utmp, wtmp, and lastlog be transitioned to retrieve the user list via systemd-logind.
On January 19, 2038, the epoch time counters set by the 32-bit time_t type will overflow. In the Glibc library, despite the implementation of the 64-bit time_t type, for compatibility with 32-bit user-space applications, the 32-bit time_t type continues to be used in some cases on 64-bit platforms. One such instance is the file /var/run/utmp, which stores data about users currently active in the system. The time field in utmp is set using a 32-bit time_t value.
Simply replacing the time field in utmp from a 32-bit to a 64-bit type will not work, as this would change the ABI of Glibc (alter the type in functions such as login(), getutid(), and utmpname()) and break compatibility with applications using utmp, including w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, and others. Due to the many potential pitfalls and the complexity involved, the idea of changing the bit-width of time_t in utmp was rejected by the Glibc developers. For the same reason, the option of using the existing free space in the utmp structure to add an additional 64-bit time field was also dismissed.
Additionally, changing the bitness of the type in utmp does not resolve other existing issues that we would also like to eliminate. For example, writing to utmp requires special rights, which necessitates granting processes additional privileges. Another problem is that the architecture of utmp allows local users to carry out DoS attacks, leading to service disruption of utmp through file lock manipulations, making it uncertain whether the contents of utmp reflect the actual state of the system. It was suggested to use an additional background process to manage access to utmp, but a process for such tasks already exists—systemd-logind—and launching yet another specialized process is not reasonable (applications would have to transmit data to two handlers simultaneously).
Even when the problem of DoS attacks is resolved, the contents of utmp remain informational and do not guarantee an accurate reflection of reality. For instance, different emulators and terminal multiplexers represent their states differently—starting five GNOME terminals will reflect one user in utmp, whereas starting five konsole or xterm terminals in KDE will show six. Similarly, the behavior of screen and tmux differs; in the former case, each session is counted as a separate user, while in the latter, only one user is reflected across all sessions.
As a result, the simplest solution suggested is to transition all applications to utilize the already existing alternative service, systemd-logind, and once there are no relevant programs accessing utmp, cease recording in utmp. To replace wtmp, it is suggested to prepare software interfaces for writing and reading user information using systemd-journald. The necessary functions for providing replacement data for utmp through libsystemd using the API sd-login.h or via DBUS have already been included in the codebase of the next release, systemd 254.
Source: opennet.ru
