Vuoden 2038 ongelma saattaa aiheuttaa osan ohjelmistosta epäonnistumisen kyseisenä vuonna. Ongelma koskee ohjelmia, jotka käyttävät POSIX-pohjaista ajan esitystapaa.
Thorsten Kukuk, tiimin johtaja SUSE Future Technologylta (Future Technology Team, kehittää openSUSE MicroOS:ää ja SLE Micriä), joka aiemmin johti SUSE LINUX Enterprise Server -projektia 10 vuotta, ehdotti /var/run/utmp-tiedoston poistamista jakeluissa ratkaisemaan täysin Y2038-ongelman Glibcissä.
Sen kanssa ehdotetaan siirrettäväksi kaikki utmp-, wtmp- ja lastlog-tiedostoja käyttävät sovellukset saadaksesi luettelon käyttäjistä, jotka käyttävät systemd-logindia.
19. tammikuuta 2038 ajastimet täyttyvät määrätyltä ajalta 32-bittisellä time_t-tyypillä. Glibcissä 64-bittisen time_t-tyypin käyttöönotosta huolimatta 32-bittistä time_t-tyyppiä käytetään edelleen joissakin tapauksissa 32-bittisillä alustoilla yhteensopivuuden ylläpitämiseksi 64-bittisten käyttäjätilasovellusten kanssa.
Utmp/utmpx:n kanssa glibc:llä on kaksi pääongelmaa esim. x86-64:ssä:
Aikaa varten käytetään 32-bittistä time_t-kenttää, joka vuotaa yli 2038:ssa
On suunnitteluongelmia, jotka sallivat DoS-hyökkäyksen (utmp/wtmp-esto antaa etuoikeutetulle käyttäjälle mahdollisuuden kieltää palvelu)
Glibc-kehittäjien analyysi toisesta ongelmasta osoitti, että utmp/utmpx-käytön käsittelemiseen tarvittaisiin ylimääräinen demoni.Vaikka ongelmia on muitakin...
Yksi tällainen tapaus on tiedosto /var/run/utmp, joka tallentaa tietoja järjestelmään tällä hetkellä yhteydessä olevista käyttäjistä. Utmp:n aikakenttä asetetaan käyttämällä 32-bittistä time_t-arvoa.
Mainitaan, että Pelkästään utmp-kentän muuttaminen ajan myötä 32-bittisestä tyypistä 64-bittiseksi ei toimi, koska tämä muuttaa Glibc ABI:n (tyyppi muuttuu funktioissa, kuten login(), getutid() ja utmpname()) ja katkaisee yhteensopivuuden utmp:ta käyttävien sovellusten kanssa, mukaan lukien w, who, käytettävyysaika, kirjautuminen, su, sudo, useradd , systemd, sysvinit, tcsh, xterm näytönohjaimet, emacs, openssh, qemu, samba, rsyslog jne.
Mahdollisten sudenkuopat ja ahkeruuden vuoksi kehittäjät Glibc hylkäsi ajatuksen time_t-tyypin bittipituuden korvaamisesta utmp:ssa. Samasta syystä mahdollisuus käyttää utmp-rakenteessa käytettävissä olevaa tilaa 64-bittisen lisäaikakentän lisäämiseen on poistettu.
Tyypin bittisyvyyden muuttaminen utmp:ssa ei myöskään ratkaise muita olemassa olevia ongelmia, esimerkiksi utmp:hen kirjoittaminen vaatii erityisiä käyttöoikeuksia, mikä edellyttää prosesseille lisäoikeuksia. Toinen ongelma on, että utmp-arkkitehtuuri sallii paikallisten käyttäjien suorittaa DoS-hyökkäyksiä, jotka rikkovat utmp-palvelun manipuloimalla tiedostojen lukkoja, mikä tekee mahdottomaksi olla varma, että utmp:n sisältö vastaa järjestelmän todellista tilaa.
Ehdotettiin ylimääräisen taustaprosessin käyttöä utmp-pääsyn käsittelemiseen, mutta tällaisia tehtäviä varten on jo systemd-logind-prosessi, eikä toisen erikoisprosessin käynnistämistä suositella (sovellusten on siirrettävä tietoja kahdelle ohjaimelle samanaikaisesti).
Samaan aikaan, vaikka ongelma ratkeaisi DoS-hyökkäyksillä, utmp:n sisältö pysyy vain informatiivisena, takaamatta kuitenkaan todellisuuden heijastusta.
Esimerkiksi erilaiset pääteemulaattorit ja multiplekserit heijastavat tilaansa eri tavalla: viiden GNOME-päätteen käyttäminen johtaa yhden käyttäjän peilautumiseen utmp:ssä, kun taas viiden konsole- tai xterm-päätelaitteen käyttäminen KDE:ssä johtaa kuuteen. Samoin näytön ja tmux:n käyttäytyminen eroaa, ensimmäisessä tapauksessa jokainen istunto lasketaan erilliseksi käyttäjäksi ja toisessa vain yksi käyttäjä näkyy kaikissa istunnoissa.
Tämän seurauksena yksinkertaisin ratkaisu ehdotetaan, että kaikki sovellukset siirretään käyttämään systemd-login-palvelua olemassa oleva vaihtoehto ja lopeta kirjoittaminen utmp:hen, kun mikään oikea ohjelma ei käytä utmp:ta. Wtmp:n korvaamiseksi ehdotetaan valmistelemaan sovellusliittymiä käyttäjien tietojen kirjoittamista ja lukemista varten systemd-journaldilla.
Lopuksi on syytä mainita, että koodipohja seuraavalle versiolle systemd 254 sisältää jo tarvittavat toiminnot tarjota korvaavia utmp-tietoja libsystemdin kautta käyttämällä sd-login.ho API:ta DBUS:n kautta.
Jos olet kiinnostunut tietämään siitä lisää, voit tutustua yksityiskohtiin Seuraavassa linkissä.