Thorsten Kukuk, serokê koma pêşkeftina teknolojiyê ya pêşerojê li SUSE (Tîma Teknolojiya Pêşerojê, OpenSUSE MicroOS û SLE Micro pêşve dike), ku berê 10 salan projeya SUSE LINUX Enterprise Server-ê rêber kir, pêşniyar kir ku ji pelê /var/run/utmp xilas bibin. di belavkirinan de ku bi tevahî pirsgirêka 2038-ê li Glibc çareser bike. Hemî serîlêdanên ku utmp, wtmp û lastlog bikar tînin têne pêşniyar kirin ku ji bo bidestxistina navnîşek bikarhênerên ku systemd-login bikar tînin werin veguheztin.
Di 19ê çileya paşîna (January) 2038 de, jimarvanên dema epokal ên ku ji hêla celebê time_t 32-bit ve hatî destnîşan kirin dê biherikin. Glibc, tevî danasîna celebek time_t 64-bit, di hin rewşan de li ser platformên 32-bit karanîna celebek time_t 64-bit berdewam dike da ku bi sepanên cîhê bikarhênerê 32-bit re hevahengiyê biparêze. Bûyerek weha pelê /var/run/utmp e, ku daneyên li ser bikarhênerên ku niha têketî pergalê hilîne. Qada demê di utmp de bi karanîna nirxek time_t 32-bit tête diyar kirin.
Bi tenê veguheztina qada demê ya di utmp-ê de ji celebek 32-bit berbi celebek 64-bit dê nexebite, ji ber ku ev ê bibe sedema guherînek di Glibc ABI de (cure dê di fonksiyonên wekî têketin (), getutid () û utmpname de biguhere. ()) û têkbirina lihevhatina bi sepanên ku utmp bikar tînin, di nav de w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, rêveberên xuyangkirina xterm, emacs, openssh, qemu, samba, rsyslog, hwd. Ji ber pirbûna kêmasiyên mimkun û tevliheviyê, ramana guherandina tîpa time_t di utmp de ji hêla pêşdebirên Glibc ve hate red kirin. Ji ber heman sedemê, vebijarka karanîna cîhê belaş a berdest di avahiya utmp-ê de ji bo lê zêdekirina zeviyek dema 64-bit ya din hate avêtin.
Wekî din, guheztina kûrahiya bit-a tîpê di utmp-ê de pirsgirêkên din ên heyî çareser nake, ku ez jî dixwazim jê xelas bikim. Mînakî, nivîsandina utmp destûrnameyên taybetî hewce dike, ku hewce dike ku pêvajoyên îmtiyazên zêde werin dayîn. Pirsgirêkek din ev e ku mîmariya utmp destûrê dide bikarhênerên herêmî ku êrişên DoS-ê pêk bînin, ku dibe sedema têkçûna karûbarê utmp bi manîpulekirina qefleyên pelan, ku ne gengaz e ku meriv pê ewle bibe ku naveroka utmp rewşa rastîn di pergalê de nîşan dide. Pêşniyar kirin ku meriv pêvajoyek paşverû ya pêvek bikar bîne da ku bigihîje utmp, lê ji bo karên weha jixwe pêvajoyek pergalê-logind heye û destpêkirina pêvajoyek din a pispor nayê şîret kirin (serlêdan dê neçar bin ku daneyan bi hevdemî veguhezînin du hilberan).
Di heman demê de, tewra dema ku pirsgirêk bi êrişên DoS re were çareser kirin, naveroka utmp tenê agahdarî dimîne û ronîkirina rastiyê garantî nake. Mînakî, emulatorên cihêreng û multiplekserên termînalê rewşa xwe cûda nîşan didin - destpêkirina pênc termînalên GNOME dê bibe encamê ku bikarhênerek di utmp de were xuyang kirin, û destpêkirina pênc termînalên konsole an xterm di KDE de dê bibe şeş encam. Tevgera ekran û tmux bi heman rengî cûda ye: Di doza yekem de, her danişîn wekî bikarhênerek cûda tê hesibandin, û di ya duyemîn de, tenê bikarhênerek ji bo hemî danişînan tê xuyang kirin.
Wekî encamek, wekî çareseriya herî hêsan, tê pêşniyar kirin ku hemî serîlêdanan veguhezînin da ku karûbarê alternatîfa heyî ya systemd-logind bikar bînin û, piştî ku bernameyên heyî negihêjin utmp-ê, tomarkirina li utmp rawestînin. Ji bo şûna wtmp, tê pêşniyar kirin ku navgînên nermalavê ji bo nivîsandin û xwendina agahdariya li ser bikarhênerên ku systemd-journald bikar tînin amade bikin. Bingeha kodê ya ji bo serbestberdana paşîn ya systemd 254 jixwe fonksiyona pêwîst dihewîne da ku daneyên veguheztina utmp bi libsystemd ve bi karanîna sd-login.h API an bi DBUS ve peyda bike.
Source: opennet.ru