Torsten Kukuk, Leiter der Future Technology Team bei SUSE, das openSUSE MicroOS und SLE Micro entwickelt, und zuvor 10 Jahre lang Projektleiter von SUSE LINUX Enterprise Server, hat vorgeschlagen, die Datei /var/run/utmp in den Distributionen 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 Benutzerliste ĂŒber systemd-logind umgestellt werden.
Am 19. Januar 2038 wird es zu einem Ăberlauf der epochalen Zeitstempel kommen, die durch den 32-Bit-Typ time_t festgelegt sind. In der Glibc-Bibliothek wird trotz der EinfĂŒhrung des 64-Bit-Typs time_t, um die KompatibilitĂ€t mit 32-Bit-Anwendungen zu wahren, in einigen FĂ€llen auf 64-Bit-Plattformen weiterhin der 32-Bit-Typ time_t verwendet. Ein solches Beispiel ist die Datei /var/run/utmp, die die Daten der aktuell im System arbeitenden Benutzer speichert. Das Zeitfeld in utmp wird mit einem 32-Bit-Wert von time_t definiert.
Das einfache Ersetzen des Zeitfelds in utmp von einem 32-Bit- auf einen 64-Bit-Typ ist nicht möglich, da dies zu einer Ănderung des ABI von 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 â darunter w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm, Display-Manager, emacs, openssh, qemu, samba, rsyslog usw. â beeintrĂ€chtigen wĂŒrde. Aufgrund der Vielzahl möglicher Fallstricke und der KomplexitĂ€t wurde die Idee, den Typ time_t in utmp zu Ă€ndern, von den Entwicklern von Glibc verworfen. Aus demselben Grund wurde auch die Option verworfen, den vorhandenen Freiraum in der utmp-Struktur zu nutzen, um ein zusĂ€tzliches 64-Bit-Zeitfeld hinzuzufĂŒgen.
DarĂŒber hinaus löst die Ănderung der Typenbreite in utmp nicht die anderen bestehenden Probleme, von denen man sich ebenfalls befreien möchte. Zum Beispiel benötigt man spezielle Rechte, um in utmp zu schreiben, was zusĂ€tzliche Privilegien fĂŒr die Prozesse erfordert. Ein weiteres Problem besteht darin, dass die Architektur von utmp lokale Benutzer DoS-Angriffe ermöglichen kann, die den Betrieb des utmp-Dienstes durch Manipulationen an den Sperren der Datei stören, sodass man sich nicht sicher sein kann, dass der Inhalt von utmp den tatsĂ€chlichen Zustand im System widerspiegelt. Es wurde vorgeschlagen, einen zusĂ€tzlichen Hintergrundprozess zur Handhabung des Zugriffs auf utmp zu verwenden, aber fĂŒr solche Aufgaben gibt es bereits den systemd-logind-Prozess, und es ist nicht sinnvoll, einen weiteren spezialisierten Prozess zu starten (Anwendungen mĂŒssten Daten gleichzeitig an zwei Verarbeiter ĂŒbergeben).
Selbst wenn das Problem mit den DoS-Angriffen gelöst ist, bleibt der Inhalt von utmp nur informativ und garantiert nicht die Darstellung der realen Gegebenheiten. Verschiedene Emulatoren und Terminal-Multiplexe spiegeln ihren Zustand unterschiedlich wider â das Starten von fĂŒnf GNOME-Terminals wird zu einer Anzeige von einem Benutzer in utmp fĂŒhren, wĂ€hrend das Starten von fĂŒnf konsole- oder xterm-Terminals in KDE zu sechs fĂŒhrt. Auch das Verhalten von screen und tmux ist unterschiedlich; im ersten Fall wird jede Sitzung als separater Benutzer gezĂ€hlt, wĂ€hrend im zweiten Fall nur ein Benutzer fĂŒr alle Sitzungen angezeigt wird.
Infolgedessen wird als die einfachste Lösung vorgeschlagen, alle Anwendungen auf die Nutzung des bereits bestehenden alternativen Dienstes systemd-logind umzustellen und nachdem keine relevanten Programme mehr auf utmp zugreifen, die Aufzeichnung in utmp zu beenden. FĂŒr die Ersetzung von wtmp wird vorgeschlagen, Programmierschnittstellen zur Aufzeichnung und zum Lesen von Benutzerinformationen mithilfe von systemd-journald vorzubereiten. Die notwendigen Funktionen zur Bereitstellung von ersetzenden utmp-Daten ĂŒber libsystemd unter Verwendung der API sd-login.h oder ĂŒber DBUS sind bereits in den Code-Basis des nĂ€chsten Releases systemd 254 integriert.
Quelle: opennet.ru
