Thorsten Kukuk, leier van die Future Technology Team by SUSE (Future Technology Team, ontwikkel openSUSE MicroOS en SLE Micro), wat voorheen die SUSE LINUX Enterprise Server-projek vir 10 jaar gelei het, het voorgestel om ontslae te raak van die /var/run/utmp-lêer in verspreidings om die Y2038-probleem in Glibc volledig aan te spreek. Alle toepassings wat utmp, wtmp en lastlog gebruik, word voorgestel om geskuif te word na 'n lys van gebruikers wat systemd-login gebruik.
Op 19 Januarie 2038 sal die epogtydtellers gespesifiseer deur die 32-bis time_t tipe oorloop. In Glibc, ten spyte van die bekendstelling van die 64-bis time_t-tipe, om verenigbaarheid met 32-bis-gebruikerspasietoepassings te handhaaf, word die 64-bis time_t-tipe steeds in sommige gevalle op 32-bis-platforms gebruik. Een so 'n geval is die /var/run/utmp-lêer, wat data stoor oor die gebruikers wat tans by die stelsel aangemeld is. Die tydveld in utmp word gestel deur 'n 32-bis time_t waarde te gebruik.
Om eenvoudig 'n veld in utmp oor tyd van 'n 32-bis na 'n 64-bis tipe te verander, sal nie werk nie, aangesien dit die Glibc ABI sal verander (die tipe sal verander in funksies soos login(), getutid() en utmpname()) en breek verenigbaarheid met toepassings wat utmp gebruik, insluitend w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm vertoonbestuurders, emacs, openssh, qemu, samba, rsyslog, ens. As gevolg van die oorvloed van moontlike slaggate en moeisaamheid, is die idee om die bislengte van die time_t-tipe in utmp te vervang deur die ontwikkelaars van Glibc verwerp. Om dieselfde rede is die opsie om die beskikbare spasie in die utmp-struktuur te gebruik om 'n bykomende 64-bis tydveld by te voeg, laat vaar.
Daarbenewens los die verandering van die bisdiepte van die tipe in utmp nie ander bestaande probleme op nie, waarvan ek ook graag ontslae wil raak. Byvoorbeeld, om na utmp te skryf, vereis spesiale toestemmings, wat vereis dat bykomende voorregte aan prosesse verleen moet word. Nog 'n probleem is dat die utmp-argitektuur plaaslike gebruikers toelaat om DoS-aanvalle uit te voer wat die utmp-diens breek deur manipulasie van lêerslotte, wat dit onmoontlik maak om seker te wees dat die inhoud van utmp die werklike toestand in die stelsel weerspieël. Daar is voorgestel om 'n addisionele agtergrondproses te gebruik om toegang tot utmp te hanteer, maar vir sulke take is daar reeds 'n systemd-login proses en om 'n ander gespesialiseerde proses te begin is nie raadsaam nie (toepassings sal data terselfdertyd na twee hanteerders moet oordra) .
Terselfdertyd, selfs wanneer die probleem met DoS-aanvalle opgelos word, bly die inhoud van utmp slegs inligting, wat nie 'n weerspieëling van die werklikheid waarborg nie. Byvoorbeeld, verskillende terminale emulators en multipleksers weerspieël hul toestand verskillend - om vyf GNOME-terminale te gebruik sal daartoe lei dat een gebruiker in utmp gereflekteer word, terwyl die loop van vyf konsole- of xterm-terminale in KDE sal lei tot ses. Net so verskil die gedrag van skerm en tmux, in die eerste geval word elke sessie as 'n aparte gebruiker getel, en in die tweede word slegs een gebruiker vir alle sessies gereflekteer.
As gevolg hiervan, as die eenvoudigste oplossing, word voorgestel om alle toepassings oor te dra om die reeds bestaande alternatiewe systemd-login diens te gebruik en, nadat daar geen werklike programme is wat toegang tot utmp het nie, ophou skryf na utmp. Om wtmp te vervang, word voorgestel om API's voor te berei vir die skryf en lees van inligting oor gebruikers wat systemd-journald gebruik. Die kodebasis vir die volgende vrystelling van systemd 254 bevat reeds die nodige funksies om vervangings-utmp-data te verskaf via libsystemd deur die sd-login.h API of via DBUS te gebruik.
Bron: opennet.ru