Thorsten Kukuk, Leiter des Future Technology Teams bei SUSE, das openSUSE MicroOS und SLE Micro entwickelt und zuvor 10 Jahre lang das Projekt SUSE LINUX Enterprise Server geleitet hat, hat vorgeschlagen, die Datei /var/run/utmp in Distribuitionen zu entfernen, um das Problem des Jahres 2038 in Glibc vollständig zu lösen. Alle Anwendungen, die utmp, wtmp und lastlog verwenden, sollten auf die Verwendung von systemd-logind umgestellt werden, um die Benutzerliste zu erhalten.
Am 19. Januar 2038 wird es zu einem Überlauf der epochalen Zeitstempel kommen, die durch den 32-Bit-Typ time_t definiert sind. In der Glibc-Bibliothek wird trotz der Implementierung des 64-Bit-Typs time_t in einigen Fällen auf 32-Bit time_t zurückgegriffen, um die Kompatibilität zu 32-Bit-Anwendungen zu wahren. Ein solches Beispiel ist die Datei /var/run/utmp, die Daten über Benutzer speichert, die derzeit im System aktiv sind. Das Zeitfeld in utmp wird mit einem 32-Bit-Wert von time_t definiert.
Es ist nicht einfach möglich, das Zeitfeld in utmp von einem 32-Bit- auf einen 64-Bit-Typ zu ändern, da dies zu einer Änderung des ABI der Glibc führen würde (der Typ in Funktionen wie login(), getutid() und utmpname() würde sich ändern) und die Kompatibilität mit Anwendungen, die utmp verwenden, beeinträchtigen würde. Dazu gehören unter anderem w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm, Display-Manager, emacs, openssh, qemu, samba, rsyslog usw. Aufgrund der Vielzahl möglicher Fallstricke und des damit verbundenen Aufwands wurde die Idee, die Bitbreite des Datentyps time_t in utmp zu ändern, von den Entwicklern der Glibc verworfen. Aus demselben Grund wurde auch die Möglichkeit, den bestehenden freien Raum in der Struktur utmp für die Hinzufügung eines zusätzlichen 64-Bit-Zeitfeldes zu nutzen, abgelehnt.
Darüber hinaus löst eine Änderung der Bitanzahl im utmp andere bestehende Probleme nicht, von denen man sich ebenfalls gerne befreien würde. Zum Beispiel sind spezielle Rechte erforderlich, um in utmp zu schreiben, was zusätzliche Privilegien für die Prozesse erfordert. Ein weiteres Problem ist, dass die Architektur von utmp es lokalen Benutzern ermöglicht, DoS-Attacken durchzuführen, die die Funktionsweise des utmp-Dienstes beeinträchtigen können, indem sie mit den Sperren auf der Datei manipulieren. Daher kann nicht sichergestellt werden, dass der Inhalt von utmp den tatsächlichen Zustand im System widerspiegelt. Um den Zugriff auf utmp zu verwalten, wurde vorgeschlagen, einen zusätzlichen Hintergrundprozess zu verwenden, aber für solche Aufgaben gibt es bereits den Prozess systemd-logind, und das Starten eines weiteren spezialisierten Prozesses ist nicht sinnvoll (Anwendungen müssten die Daten gleichzeitig an zwei Verarbeiter übergeben).
Selbst wenn das Problem mit DoS-Angriffen gelöst ist, bleibt der Inhalt von utmp nur informativ und garantiert nicht die tatsächliche Realität. Zum Beispiel reflektieren verschiedene Emulatoren und Multiplexer von Terminals ihren Status unterschiedlich – das Starten von fünf GNOME-Terminals führt im utmp zu einem Benutzer, während das Starten von fünf konsole- oder xterm-Terminals in KDE zu sechs führt. Ebenso verhält sich das Verhalten von screen und tmux, wobei im ersten Fall jede Sitzung als separater Benutzer gezählt wird, während im zweiten Fall nur ein Benutzer für alle Sitzungen angezeigt wird.
Das einfachste Lösungsvorschlag besteht darin, alle Anwendungen auf den bereits bestehenden alternativen Dienst systemd-logind umzustellen. Sobald keine Programme mehr bestehen, die auf utmp zugreifen, kann die Aufzeichnung in utmp eingestellt werden. Für die Ersetzung von wtmp wird vorgeschlagen, Programmierschnittstellen (APIs) zur Aufzeichnung und zum Lesen von Benutzerinformationen mithilfe von systemd-journald vorzubereiten. Die erforderlichen Funktionen zur Bereitstellung von Ersatzdaten für utmp über libsystemd unter Verwendung der API sd-login.h oder über DBUS sind bereits in den Code von systemd 254 aufgenommen worden.
Quelle: opennet.ru
