Thorsten Kukuk, leader of the Future Technology Team at SUSE (Future Technology Team, develops openSUSE MicroOS and SLE Micro), who previously led the SUSE LINUX Enterprise Server project for 10 years, suggested getting rid of the /var/run/utmp file in distributions to fully address the Y2038 problem in Glibc. All applications using utmp, wtmp, and lastlog are proposed to be moved to getting a list of users using systemd-logind.
On January 19, 2038, the epoch time counters specified by the 32-bit time_t type will overflow. In Glibc, despite the introduction of the 64-bit time_t type, to maintain compatibility with 32-bit user-space applications, the 64-bit time_t type is still used in some cases on 32-bit platforms. One such case is the /var/run/utmp file, which stores data about the users currently logged into the system. The time field in utmp is set using a 32-bit time_t value.
Simply changing a field in utmp over time from a 32-bit to a 64-bit type will not work, as this will change the Glibc ABI (the type will change in functions like login(), getutid() and utmpname()) and break compatibility with applications that use utmp, including w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, etc. Due to the abundance of possible pitfalls and laboriousness, the idea of ββreplacing the bit length of the time_t type in utmp was rejected by the developers of Glibc. For the same reason, the option to use the available space in the utmp structure to add an additional 64-bit time field was dropped.
In addition, changing the bit depth of the type in utmp does not solve other existing problems, which I would also like to get rid of. For example, writing to utmp requires special permissions, which requires additional privileges to be granted to processes. Another problem is that the utmp architecture allows local users to perform DoS attacks that break the utmp service through manipulation of file locks, making it impossible to be sure that the contents of utmp reflect the real state in the system. It was proposed to use an additional background process to handle access to utmp, but for such tasks there is already a systemd-logind process and starting another specialized process is not advisable (applications will have to transfer data to two handlers at the same time).
At the same time, even when solving the problem with DoS attacks, the content of utmp remains only informational, not guaranteeing a reflection of reality. For example, different terminal emulators and multiplexers reflect their state differently - running five GNOME terminals will result in one user being reflected in utmp, while running five konsole or xterm terminals in KDE will result in six. Similarly, the behavior of screen and tmux differs, in the first case each session is counted as a separate user, and in the second only one user is reflected for all sessions.
As a result, as the simplest solution, it is proposed to transfer all applications to use the already existing alternative systemd-logind service and, after there are no actual programs accessing utmp, stop writing to utmp. To replace wtmp, it is proposed to prepare APIs for writing and reading information about users using systemd-journald. The codebase for the next release of systemd 254 already includes the necessary functions to provide replacement utmp data via libsystemd using the sd-login.h API or via DBUS.
Source: opennet.ru