Thorsten Kukuk, Leiter des Future Technology Teams bei SUSE (Future Technology Team, entwickelt openSUSE MicroOS und SLE Micro), der zuvor 10 Jahre lang das SUSE LINUX Enterprise Server-Projekt leitete, schlug vor, die Datei /var/run/utmp in zu entfernen Distributionen, um das Y2038-Problem in Glibc vollständig zu lösen. Es wird vorgeschlagen, alle Anwendungen, die utmp, wtmp und lastlog verwenden, so umzustellen, dass sie eine Liste von Benutzern mithilfe von systemd-logind abrufen.
Am 19. Januar 2038 kommt es zu einem Überlauf der durch den 32-Bit-Typ time_t angegebenen Epochenzeitzähler. Um die Kompatibilität mit 64-Bit-User-Space-Anwendungen aufrechtzuerhalten, wird in Glibc trotz der Einführung des 32-Bit-Typs time_t in einigen Fällen immer noch der 64-Bit-Typ time_t auf 32-Bit-Plattformen verwendet. Ein solcher Fall ist die Datei /var/run/utmp, die Daten über die aktuell am System angemeldeten Benutzer speichert. Das Zeitfeld in utmp wird mithilfe eines 32-Bit-time_t-Werts festgelegt.
Das einfache Ändern eines Felds in utmp von einem 32-Bit-Typ in einen 64-Bit-Typ im Laufe der Zeit wird nicht funktionieren, da sich dadurch die Glibc-ABI ändert (der Typ ändert sich in Funktionen wie login(), getutid() und utmpname() ) und unterbrechen die Kompatibilität mit Anwendungen, die utmp verwenden, einschließlich w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display manager, emacs, opensh, qemu, samba, rsyslog usw. Aufgrund der Fülle möglicher Fallstricke und des Aufwands wurde die Idee, die Bitlänge des Typs time_t in utmp zu ersetzen, von den Glibc-Entwicklern abgelehnt. Aus dem gleichen Grund wurde die Option, den verfügbaren Platz in der utmp-Struktur zu nutzen, um ein zusätzliches 64-Bit-Zeitfeld hinzuzufügen, gestrichen.
Darüber hinaus löst die Änderung der Bittiefe des Typs in utmp keine anderen bestehenden Probleme, die ich ebenfalls beseitigen möchte. Zum Schreiben in utmp sind beispielsweise spezielle Berechtigungen erforderlich, die die Gewährung zusätzlicher Berechtigungen für Prozesse erfordern. Ein weiteres Problem besteht darin, dass die utmp-Architektur es lokalen Benutzern ermöglicht, DoS-Angriffe durchzuführen, die den utmp-Dienst durch Manipulation von Dateisperren unterbrechen, wodurch es unmöglich ist, sicher zu sein, dass der Inhalt von utmp den tatsächlichen Zustand im System widerspiegelt. Es wurde vorgeschlagen, einen zusätzlichen Hintergrundprozess zu verwenden, um den Zugriff auf utmp zu verwalten, aber für solche Aufgaben gibt es bereits einen systemd-logind-Prozess und das Starten eines weiteren spezialisierten Prozesses ist nicht ratsam (Anwendungen müssen Daten gleichzeitig an zwei Handler übertragen). .
Gleichzeitig bleibt der Inhalt von utmp auch bei der Lösung des Problems mit DoS-Angriffen nur informativ und garantiert kein Abbild der Realität. Beispielsweise spiegeln verschiedene Terminalemulatoren und Multiplexer ihren Status unterschiedlich wider – wenn fünf GNOME-Terminals ausgeführt werden, wird ein Benutzer in utmp angezeigt, während die Ausführung von fünf Konsolen- oder Xterm-Terminals in KDE zu sechs führt. Ebenso unterscheidet sich das Verhalten von screen und tmux. Im ersten Fall wird jede Sitzung als separater Benutzer gezählt, im zweiten Fall wird nur ein Benutzer für alle Sitzungen berücksichtigt.
Als einfachste Lösung wird daher vorgeschlagen, alle Anwendungen auf die Nutzung des bereits vorhandenen alternativen systemd-logind-Dienstes zu übertragen und das Schreiben in utmp zu beenden, sobald keine tatsächlichen Programme mehr auf utmp zugreifen. Um wtmp zu ersetzen, wird vorgeschlagen, APIs zum Schreiben und Lesen von Informationen über Benutzer mithilfe von systemd-journald vorzubereiten. Die Codebasis für die nächste Version von systemd 254 enthält bereits die notwendigen Funktionen, um Ersatz-UTMP-Daten über libsystemd mithilfe der sd-login.h-API oder über DBUS bereitzustellen.
Source: opennet.ru