Thorsten Kukuk, team leader from SUSE Future Technology (Future Technology Team, develops openSUSE MicroOS and SLE Micr ), 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 issue in Glibc.
With that it is proposed to move all applications that use utmp, wtmp and lastlog to get a list of users using systemd-logind.
On January 19, 2038, the timers will overflow of specified period by the 32-bit time_t type. In Glibc, despite the introduction of the 64-bit time_t type, to maintain compatibility with 32-bit userspace applications, the 32-bit time_t type is still used in some cases on 64-bit platforms.
There are two main problems with utmp/utmpx with glibc on e.g. x86-64:
A 32-bit time_t field is used for the time, which will overflow at 2038
There are design issues that allow a DoS attack ( utmp/wtmp blocking allows an unprivileged user to deny service )
An analysis of the second problem by the glibc developers showed that an additional daemon would be required to handle utmp/utmpx access.
Although there are some more problems...
One such case is the file /var/run/utmp, which stores data about the users currently connected to the system. The time field in utmp is set using a 32-bit time_t value.
It is mentioned that, simply changing a field in utmp over time from a 32-bit type to a 64-bit type won't 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 potential pitfalls and industriousness, the developers of Glibc rejected the idea of replacing the bit length of the time_t type in utmp. For the same reason, the option to use the available space in the utmp structure to add an additional 64-bit time field has been removed.
Also, changing the bit depth of the type in utmp does not solve other existing problems, for example, writing to utmp requires special permissions, which requires processes to be granted additional privileges. Another problem is that the utmp architecture allows local users to perform DoS attacks that break the utmp service by manipulating file locks, making it impossible to be sure that the content of utmp reflects the actual state of 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 it is not recommended to start another specialized process (applications will have to transfer data to two controllers at the same time).
At the same time, even by solving the problem with DoS attacks, the content of utmp remains only informative, without 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 mirrored 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 port all applications to use the systemd-logind service alternative already existing and, after no real programs are 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.
Finally, it is worth mentioning that the code base for the next version of systemd 254 already includes the necessary functions to provide replacement utmp data via libsystemd using the sd-login.ho API via DBUS.
If you are interested in knowing more about it, you can consult the details In the following link.
Be the first to comment