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\u00e4ndig zu l\u00f6sen. Alle Anwendungen, die utmp, wtmp und lastlog verwenden, sollten auf die Verwendung von systemd-logind umgestellt werden, um die Benutzerliste zu erhalten. <\/p>\n
Am 19. Januar 2038 wird es zu einem \u00dcberlauf 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\u00e4llen auf 32-Bit time_t zur\u00fcckgegriffen, um die Kompatibilit\u00e4t zu 32-Bit-Anwendungen zu wahren. Ein solches Beispiel ist die Datei \/var\/run\/utmp, die Daten \u00fcber Benutzer speichert, die derzeit im System aktiv sind. Das Zeitfeld in utmp wird mit einem 32-Bit-Wert von time_t definiert. <\/p>\n
Es ist nicht einfach m\u00f6glich, das Zeitfeld in utmp von einem 32-Bit- auf einen 64-Bit-Typ zu \u00e4ndern, da dies zu einer \u00c4nderung des ABI der Glibc f\u00fchren w\u00fcrde (der Typ in Funktionen wie login(), getutid() und utmpname() w\u00fcrde sich \u00e4ndern) und die Kompatibilit\u00e4t mit Anwendungen, die utmp verwenden, beeintr\u00e4chtigen w\u00fcrde. Dazu geh\u00f6ren 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\u00f6glicher Fallstricke und des damit verbundenen Aufwands wurde die Idee, die Bitbreite des Datentyps time_t in utmp zu \u00e4ndern, von den Entwicklern der Glibc verworfen. Aus demselben Grund wurde auch die M\u00f6glichkeit, den bestehenden freien Raum in der Struktur utmp f\u00fcr die Hinzuf\u00fcgung eines zus\u00e4tzlichen 64-Bit-Zeitfeldes zu nutzen, abgelehnt. <\/p>\n
Dar\u00fcber hinaus l\u00f6st eine \u00c4nderung der Bitanzahl im utmp andere bestehende Probleme nicht, von denen man sich ebenfalls gerne befreien w\u00fcrde. Zum Beispiel sind spezielle Rechte erforderlich, um in utmp zu schreiben, was zus\u00e4tzliche Privilegien f\u00fcr die Prozesse erfordert. Ein weiteres Problem ist, dass die Architektur von utmp es lokalen Benutzern erm\u00f6glicht, DoS-Attacken durchzuf\u00fchren, die die Funktionsweise des utmp-Dienstes beeintr\u00e4chtigen k\u00f6nnen, indem sie mit den Sperren auf der Datei manipulieren. Daher kann nicht sichergestellt werden, dass der Inhalt von utmp den tats\u00e4chlichen Zustand im System widerspiegelt. Um den Zugriff auf utmp zu verwalten, wurde vorgeschlagen, einen zus\u00e4tzlichen Hintergrundprozess zu verwenden, aber f\u00fcr solche Aufgaben gibt es bereits den Prozess systemd-logind, und das Starten eines weiteren spezialisierten Prozesses ist nicht sinnvoll (Anwendungen m\u00fcssten die Daten gleichzeitig an zwei Verarbeiter \u00fcbergeben). <\/p>\n
Selbst bei der Behebung von DoS-Angriffen bleibt der Inhalt von utmp lediglich informativ und garantiert keine echte Abbildung der Realit\u00e4t. Beispielsweise zeigen unterschiedliche Emulatoren und Multiplexer von Terminals ihren Zustand unterschiedlich an \u2014 der Start von f\u00fcnf GNOME-Terminals f\u00fchrt zur Anzeige eines Benutzers in utmp, w\u00e4hrend der Start von f\u00fcnf konsole- oder xterm-Terminals in KDE sechs anzeigt. \u00c4hnlich verh\u00e4lt es sich bei screen und tmux: Im ersten Fall wird jede Sitzung als eigener Benutzer gez\u00e4hlt, w\u00e4hrend im zweiten Fall nur ein Benutzer f\u00fcr alle Sitzungen angezeigt wird. <\/p>\n