Fir Glibc vum 2038 Problem ze befreien, gëtt proposéiert opzehalen utmp ze benotzen

Den Thorsten Kukuk, Leader vun der zukünfteg Technologieentwécklungsgrupp bei SUSE (Future Technology Team, entwéckelt openSUSE MicroOS an SLE Micro), dee virdru de SUSE LINUX Enterprise Server Projet fir 10 Joer gefouert huet, huet virgeschloen d' /var/run/utmp Datei ze läschen. a Verdeelungen fir den 2038 Problem am Glibc voll unzegoen. All Uwendungen déi utmp, wtmp a lastlog benotzen gi proposéiert fir ëmgewandelt ze ginn fir eng Lëscht vu Benotzer ze kréien déi systemd-login benotzen.

Den 19. Januar 2038 wäerten d'epochal Zäitzähler, déi vum 32-Bit Time_t Typ spezifizéiert sinn, iwwerlafen. Glibc, trotz der Aféierung vun engem 64-Bit time_t Typ, setzt weider e 32-Bit Time_t Typ an e puer Fäll op 64-Bit Plattformen ze benotzen fir Kompatibilitéit mat 32-Bit Benotzerraumapplikatiounen z'erhalen. Een esou Fall ass d' /var/run/utmp Datei, déi Daten iwwer Benotzer späichert déi momentan an de System ageloggt sinn. D'Zäitfeld an utmp gëtt mat dem 32-Bit time_t Wäert uginn.

Einfach d'Zäitfeld an utmp vun engem 32-Bit op e 64-Bit Typ z'ersetzen funktionnéiert net, well dëst zu enger Ännerung am Glibc ABI féiert (den Typ ännert sech a Funktiounen wéi Login (), getutid () an utmpname ()) a briechen Kompatibilitéit mat Uwendungen déi utmp benotzen, dorënner w, wien, uptime, Login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm Displaymanager, emacs, openssh, qemu, samba, rsyslog, etc. Wéinst der Iwwerfloss vu méigleche Fallen a Komplexitéit ass d'Iddi fir den time_t Typ an utmp ze ersetzen vun de Glibc Entwéckler refuséiert. Aus dem selwechte Grond gouf d'Optioun fir de verfügbare fräie Raum an der utmp Struktur ze benotzen fir en zousätzlech 64-Bit Zäitfeld ze addéieren gouf verworf.

Zousätzlech, d'Ännere vun der Typ Bittiefe an utmp léist keng aner existent Probleemer, déi ech och gär hätt lass ze ginn. Zum Beispill, Schreiwen op utmp erfuerdert speziell Permissiounen, wat Prozesser erfuerdert fir zousätzlech Privilegien ze kréien. En anere Problem ass datt d'utmp-Architektur lokal Benotzer erlaabt DoS-Attacke auszeféieren, wat zu enger Stéierung vum utmp-Service duerch Manipulatioun vu Dateiespären féiert, wat et onméiglech mécht sécher ze sinn datt d'Inhalter vum utmp den realen Zoustand am System reflektéieren. Et gouf proposéiert en zousätzlechen Hannergrondprozess ze benotzen fir den Zougang zu utmp ze handhaben, awer fir sou Aufgaben gëtt et schonn e Systemd-Login-Prozess an en anere spezialiséierte Prozess ze starten ass net unzeroden (Applikatiounen mussen Daten op zwee Handler gläichzäiteg transferéieren).

Zur selwechter Zäit, och wann Dir de Problem mat DoS Attacken léist, bleift den Inhalt vun utmp nëmmen Informatioun a garantéiert keng Reflexioun vun der Realitéit. Zum Beispill, verschidde Emulatoren an Terminalmultiplexer reflektéieren hiren Zoustand anescht - fënnef GNOME-Terminals lancéiere wäert zu engem Benotzer an utmp reflektéiert ginn, a fënnef Konsole- oder xterm-Terminaler an KDE starten wäert zu sechs resultéieren. D'Behuele vum Écran an tmux ass ähnlech anescht: am éischte Fall gëtt all Sessioun als separat Benotzer gezielt, an an der zweeter gëtt nëmmen ee Benotzer fir all Sessiounen reflektéiert.

Als Resultat, als déi einfachst Léisung, gëtt proposéiert all Uwendungen ze transferéieren fir de schonn existent alternativ Systemd-Logind Service ze benotzen an, nodeems et keng aktuell Programmer op utmp zougänglech sinn, opzehalen op utmp opzehuelen. Fir wtmp z'ersetzen, gëtt proposéiert Software-Interfaces virzebereeden fir d'Informatioun iwwer d'Benotzer ze schreiwen an ze liesen déi systemd-journald benotzen. D'Codebase fir déi nächst Verëffentlechung vu systemd 254 enthält schonn déi néideg Funktionalitéit fir utmp Ersatzdaten iwwer libsystemd mat der sd-login.h API oder iwwer DBUS ze liwweren.

Source: opennet.ru

Setzt e Commentaire