Thorsten Kukuk, leiðtogi framtíðartækniþróunarhóps SUSE (Future Technology Team, þróar openSUSE MicroOS og SLE Micro), sem áður stýrði SUSE LINUX Enterprise Server verkefninu í 10 ár, lagði til að losa sig við /var/run/utmp skrána í dreifingum til að taka á 2038 vandamálinu í Glibc að fullu. Lagt er til að öllum forritum sem nota utmp, wtmp og lastlog verði breytt til að fá lista yfir notendur sem nota systemd-login.
Þann 19. janúar, 2038, flæða tímabilstímateljararnir sem tilgreindir eru af 32-bita time_t gerðinni yfir. Glibc, þrátt fyrir að kynna 64-bita time_t gerð, heldur áfram að nota 32-bita time_t gerð í sumum tilfellum á 64-bita kerfum til að viðhalda eindrægni við 32-bita notendarýmisforrit. Eitt slíkt tilvik er /var/run/utmp skráin, sem geymir gögn um notendur sem eru skráðir inn í kerfið. Tímareiturinn í utmp er tilgreindur með því að nota 32-bita time_t gildi.
Einfaldlega að skipta út tímareitnum í utmp úr 32-bita í 64-bita gerð mun ekki virka, þar sem þetta mun leiða til breytinga á Glibc ABI (gerðin mun breytast í aðgerðum eins og login(), getutid() og utmpname ()) og brýtur eindrægni við forrit sem nota utmp, þar á meðal w, who, spenntur, innskráning, su, sudo, useradd, systemd, sysvinit, tcsh, xterm skjástjórar, emacs, openssh, qemu, samba, rsyslog o.s.frv. Vegna gnægð mögulegra gildra og flókinna, var hugmyndinni um að skipta um time_t gerð í utmp hafnað af Glibc þróunaraðilum. Af sömu ástæðu var möguleikanum á að nota tiltækt laust pláss í utmp uppbyggingunni til að bæta við 64 bita tímareit til viðbótar hent.
Að auki leysir það ekki önnur núverandi vandamál að breyta bitadýpt tegundarinnar í utmp, sem ég myndi líka vilja losna við. Til dæmis, að skrifa til utmp krefst sérstakra réttinda, sem krefst þess að ferlum sé veitt viðbótarréttindi. Annað vandamál er að utmp arkitektúrinn gerir staðbundnum notendum kleift að framkvæma DoS árásir, sem leiðir til truflunar á utmp þjónustunni með meðferð á skráalásum, sem gerir það ómögulegt að vera viss um að innihald utmp endurspegli raunverulegt ástand í kerfinu. Lagt var til að nota viðbótar bakgrunnsferli til að sjá um aðgang að utmp, en fyrir slík verkefni er nú þegar til systemd-innskráningarferli og ekki er ráðlegt að hefja annað sérhæft ferli (forrit þurfa að flytja gögn til tveggja meðhöndlunaraðila samtímis).
Á sama tíma, jafnvel þegar vandamálið er leyst með DoS árásum, er innihald utmp aðeins til upplýsinga og ábyrgist ekki endurspeglun raunveruleikans. Til dæmis endurspegla mismunandi keppinautar og útstöðvarfjölbreytileikar stöðu sína á mismunandi hátt - að ræsa fimm GNOME útstöðvar mun leiða til þess að einn notandi endurspeglast í utmp, og að ræsa fimm konsole eða xterm útstöðvar í KDE mun leiða til sex. Hegðun skjár og tmux er álíka ólík: í fyrra tilvikinu er hver lota talin sem sérstakur notandi og í því síðara endurspeglast aðeins einn notandi fyrir allar lotur.
Þar af leiðandi, sem einfaldasta lausnin, er lagt til að flytja öll forrit til að nota þegar fyrirliggjandi aðra systemd-login þjónustu og, eftir að engin núverandi forrit hafa aðgang að utmp, stöðva upptöku í utmp. Í stað wtmp er lagt til að útbúa hugbúnaðarviðmót til að skrifa og lesa upplýsingar um notendur sem nota systemd-journald. Kóðagrunnurinn fyrir næstu útgáfu af systemd 254 inniheldur nú þegar nauðsynlega virkni til að veita utmp skiptigögn í gegnum libsystemd með því að nota sd-login.h API eða í gegnum DBUS.
Heimild: opennet.ru