Thorsten Kukuk, lideri i grupit për zhvillimin e teknologjive të së ardhmes në kompaninë SUSE, i cili ka drejtuar projektin SUSE LINUX Enterprise Server për 10 vjet, ka propozuar që të hiqet skedari /var/run/utmp në distribuimet për të zgjidhur plotësisht problemin e vitit 2038 në Glibc. Të gjitha aplikacionet që përdorin utmp, wtmp dhe lastlog, rekomandohet të kalojnë në marrjen e listës së përdoruesve përmes systemd-logind.
Më 19 janar 2038 do të ndodhi tejkalimi i numrave të epokës, të caktuar nga tipi 32-bit time_t. Në bibliotekën Glibc, pavarësisht nga implementimi i tipit 64-bit time_t, për të ruajtur kompatibilitetin me aplikacionet 32-bit, në disa raste në platformat 64-bit vazhdon të përdoret tipi 32-bit time_t. Një nga këto raste është skedari /var/run/utmp, i cili ruan të dhëna rreth përdoruesve që aktualisht janë duke punuar në sistem. Fusha me kohë në utmp caktohet duke përdorur një vlerë 32-bit time_t.
Thjesht zëvendësimi i fushës me kohën në utmp nga tipi 32-bit në 64-bit nuk do të funksionojë, pasi kjo do të çojë në ndryshimin e ABI Glibc (do të ndryshojë tipi në funksione si login(), getutid() dhe utmpname()) dhe do të prishë kompatibilitetin me aplikacionet që përdorin utmp, duke përfshirë w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, menaxherët e ekranit tcsh, xterm, emacs, openssh, qemu, samba, rsyslog, etj. Për shkak të numrit të madh të potencialeve pengesave dhe punës së madhe, ideja e zëvendësimit të tipit time_t në utmp është refuzuar nga zhvilluesit e Glibc. Po për të njëjtën arsye është hedhur poshtë edhe varianti i përdorimit të hapësirës së lirë në strukturën utmp për të shtuar një fushë shtesë 64-bit për kohën.
Për më tepër, ndryshimi i tipit në utmp nuk zgjidh probleme të tjera që gjithashtu duhet të eliminohen. Për shembull, për të shkruar në utmp kërkohen privilegje speciale, gjë që kërkon që proceset të kenë privilegje të shtesë. Një problem tjetër është se arkitektura e utmp lejon që përdoruesit lokalë të kryejnë sulme DoS që shkaktojnë ndërprerje të shërbimit utmp përmes manipulimeve me bllokimet në skedar, duke bërë që të mos jetë i sigurt se përmbajtja e utmp reflekton gjendjen reale në sistem. Për të menaxhuar aksesin në utmp, është propozuar të përdoret një proces i ri në sfond, por për këto detyra tashmë egziston procesi systemd-logind dhe nisja e një procesi të specializuar nuk është e arsyeshme (aplikacionet do të duhet të dërgojnë të dhëna në dy trajtues në të njëjtën kohë).
MegjithatĂ«, edhe kur zgjidhet problemi me sulmet DoS, pĂ«rmbajtja e utmp mbetet vetĂ«m informuese, pa garantuar reflektimin e realitetit tĂ« vĂ«rtetĂ«. PĂ«r shembull, emulatorĂ«t e ndryshĂ«m dhe shumĂ«fokuset e termineve pasqyrojnĂ« gjendjen e tyre ndryshe â nisja e pesĂ« terminaleve GNOME do tĂ« rezultojĂ« nĂ« pasqyrimin e njĂ« pĂ«rdoruesi nĂ« utmp, ndĂ«rsa nisja e pesĂ« terminaleve konsole ose xterm nĂ« KDE do tĂ« pasqyrojĂ« gjashtĂ«. Po ashtu, sjellja e screen dhe tmux ndryshon; nĂ« rastin e parĂ«, çdo seancĂ« pyrrohet si njĂ« pĂ«rdorues i veçantĂ«, ndĂ«rsa nĂ« rastin e dytĂ« pasqyrohet vetĂ«m njĂ« pĂ«rdorues pĂ«r tĂ« gjitha seancat.
Si rezultat, si zgjidhje më e thjeshtë propozohet kalimi i të gjitha aplikacioneve në përdorimin e shërbimit alternativ ekzistues systemd-logind dhe, pasi të mos mbeten programe aktuale që përdorin utmp, të ndalojë regjistrimin në utmp. Për zëvendësimin e wtmp, propozohet të përgatiten ndërfaqet për regjistrimin dhe leximin e informacionit rreth përdoruesve përmes systemd-journald. Në kodin e bazës së versionit të ardhshëm systemd 254 janë përfshirë tashmë funksionet e nevojshme për të ofruar të dhëna që zëvendësojnë utmp përmes libsystemd duke përdorur API sd-login.h ose përmes DBUS.
Burimi: opennet.ru
