Thorsten Kukuk, the leader of SUSE’s development group, has presented a solution to the upcoming 2038 problem in Glibc by proposing the removal of the file “/var/run/UTMP” in distributions. Kukuk, who previously managed the SUSE Linux Enterprise Server project, is a member of the Future Technology Team that develops Opensuse Microos and Sle Micro. The proposal suggests transferring all applications that use UTMP, WTMP and Lastlog to a list of users using Systemd-Logind.
The 2038 problem is a result of an overflow of epoch-making meters specified by the 32-bit type Time_t that is set to take place on January 19, 2038. Despite the introduction of a 64-bit Time_t type in the GLIBC library, in some cases, a 32-bit Time_t type continues to be used on 64-bit platforms for compatibility with 32-bit user space applications. One such case is the file “/var/run/UTMP,” which stores user data currently working in the system. The field with time in UTMP is set using the 32-bit value Time_t.
Replacing the field over time in UTMP from 32-bit to 64-bit type could lead to the change in Application Binary Interface (ABI) GLIBC in functions such as Login (), Getutid (), and UTMPNAME (), leading to compatibility issues with applications like Using UTMP, Main, Who, Uptime, Login, Su, Sudo, Usrademd, Sysvinit, Tcsh, XTerm Display Managers, Emacs, Openssh, Qemu, Samba, RsySlog, among others. Due to the potential for complications and complexity, Glibc developers have rejected the idea of replacing the UTMP discharge type Time_t. Additionally, changing the type in UTMP does not solve other ongoing problems, such as special rights required to record in UTMP and the UTMP architecture allowing local users to cause DOS attacks leading to a violation of the UTMP service through manipulations with locks on a file.
To address these other problems, it was proposed to use an additional background process for processing access to UTMP, but as there is already a SystemD-Logind process in place for such tasks, launching another specialized process is not appropriate. Applications would have to transmit data simultaneously in two handlers.