Thorsten Kukuk, SUSE:n tulevaisuuden teknologian kehitysryhmän johtaja (Future Technology Team, kehittää openSUSE MicroOS:ää ja SLE Microa), joka aiemmin johti SUSE LINUX Enterprise Server -projektia 10 vuotta, ehdotti /var/run/utmp-tiedoston poistamista. jakeluissa Glibc:n 2038-ongelman ratkaisemiseksi. Kaikki utmp:ta, wtmp:tä ja lastlogia käyttävät sovellukset ehdotetaan muunnettavaksi käyttäjäluetteloksi systemd-logindin avulla.
19. tammikuuta 2038 32-bittisen time_t-tyypin määrittämät epokaaliset aikalaskurit ylittyvät. Glibc, huolimatta 64-bittisen time_t-tyypin käyttöönotosta, jatkaa 32-bittisen time_t-tyypin käyttöä joissakin tapauksissa 64-bittisissä alustoissa yhteensopivuuden ylläpitämiseksi 32-bittisten käyttäjäavaruussovellusten kanssa. Yksi tällainen tapaus on /var/run/utmp-tiedosto, joka tallentaa tietoja järjestelmään tällä hetkellä kirjautuneista käyttäjistä. Utmp:n aikakenttä määritetään käyttämällä 32-bittistä time_t-arvoa.
Pelkkä aikakentän korvaaminen utmp:ssa 32-bittisestä 64-bittiseksi ei toimi, koska tämä johtaa muutokseen Glibc ABI:ssa (tyyppi muuttuu funktioissa, kuten login(), getutid() ja utmpname ()) ja yhteensopivuuden rikkominen 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 sudenkuoppien ja monimutkaisuuden vuoksi Glibc-kehittäjät hylkäsivät ajatuksen time_t-tyypin korvaamisesta utmp:ssa. Samasta syystä mahdollisuus käyttää utmp-rakenteessa käytettävissä olevaa vapaata tilaa ylimääräisen 64-bittisen aikakentän lisäämiseen hylättiin.
Lisäksi tyypin bittisyvyyden muuttaminen utmp:ssa ei ratkaise muita olemassa olevia ongelmia, joista haluaisin myös päästä eroon. Esimerkiksi utmp:hen kirjoittaminen vaatii erityisoikeuksia, mikä edellyttää prosesseille lisäoikeuksia. Toinen ongelma on, että utmp-arkkitehtuuri sallii paikallisten käyttäjien suorittaa DoS-hyökkäyksiä, mikä johtaa utmp-palvelun häiriintymiseen tiedostolukkojen manipuloinnin kautta, mikä tekee mahdottomaksi olla varma, että utmp:n sisältö heijastaa järjestelmän todellista tilaa. Utmp-pääsyn käsittelyyn ehdotettiin ylimääräistä taustaprosessia, mutta tällaisiin tehtäviin on jo systemd-logind-prosessi, eikä toisen erikoisprosessin käynnistäminen ole suositeltavaa (sovellusten on siirrettävä tietoja kahdelle käsittelijälle samanaikaisesti).
Samaan aikaan, vaikka ongelmaa ratkaistaan DoS-hyökkäyksillä, utmp:n sisältö jää vain tiedoksi, eikä se takaa todellisuuden heijastusta. Esimerkiksi erilaiset emulaattorit ja päätemultiplekserit heijastavat tilaansa eri tavalla - viiden GNOME-päätelaitteen käynnistäminen johtaa siihen, että yksi käyttäjä näkyy utmp:ssa, ja viiden konsoli- tai xterm-päätelaitteen käynnistäminen KDE:ssä johtaa kuuteen. Näytön ja tmuxin käyttäytyminen on samoin erilainen: 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 yksinkertaisimpana ratkaisuna ehdotetaan, että kaikki sovellukset siirretään käyttämään jo olemassa olevaa vaihtoehtoista systemd-logind-palvelua ja lopetetaan tallentaminen utmp:hen sen jälkeen, kun utmp:ta käyttäviä ohjelmia ei ole. Wtmp:n korvaamiseksi ehdotetaan valmistelemaan ohjelmistorajapintoja käyttäjiä koskevien tietojen kirjoittamista ja lukemista varten systemd-journaldilla. Systemd 254:n seuraavan julkaisun koodikanta sisältää jo tarvittavat toiminnot utmp-korvaustietojen tarjoamiseen libsystemdin kautta sd-login.h API:n tai DBUS:n kautta.
Lähde: opennet.ru