Thorsten Kukuk, lideri i grupit për zhvillimin e teknologjive të së ardhmes në kompaninë SUSE (Ekipi i Teknologjive të së Ardhmes, zhvillon openSUSE MicroOS dhe SLE Micro), i cili ka drejtuar projektin SUSE LINUX Enterprise Server për 10 vjet, sugjeroi që të hiqet skedari /var/run/utmp nga shpërndarjet për të zgjidhur plotësisht problemin e vitit 2038 në Glibc. Të gjitha aplikacionet që përdorin utmp, wtmp dhe lastlog, propozohet të kalojnë në marrjen e listës së përdoruesve përmes systemd-logind.
Më 19 janar 2038 do të ndodhë mbushja e numrave të kohës epokale, të caktuar nga lloji 32-bit time_t. Në bibliotekën Glibc, megjithëse është futur lloji 64-bit time_t, për të ruajtur kompatibilitetin me aplikacionet 32-bit, në disa raste në platformat 64-bit vazhdon të përdoret lloji 32-bit time_t. Një nga këto raste është skedari /var/run/utmp, që ruan të dhënat mbi përdoruesit që aktualisht janë të lidhur në sistem. Fusha e kohës në utmp caktohet duke përdorur një vlerë 32-bit time_t.
Thjesht ndërrimi i fushës së kohës në utmp nga lloji 32-bit në 64-bit nuk do të bëhet, pasi kjo do të çojë në ndryshimin e ABI të Glibc (do të ndryshojë lloji në funksione si login(), getutid() dhe utmpname()) dhe do të dëmtojë kompatibilitetin me aplikacionet që përdorin utmp, 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ë shumë rreziqeve të mundshme dhe kompleksitetit, ideja e ndërrimit të bitëve të llojit time_t në utmp u hodh poshtë nga zhvilluesit e Glibc. Po për të njëjtën arsye, u hodh poshtë mundësia e përdorimit të hapësirës së lirë ekzistuese në strukturën utmp për shpërndarjen e një fushe 64-bit të re për kohën.
Për më tepër, ndryshimi i tipit të saktësisë në utmp nuk zgjidh problemet e tjera që duhen eliminuar. Për shembull, për regjistrimin në utmp kërkohen të drejta speciale, duke kërkuar dhënien e privilegjeve të mëtejshme proceseve. Një problem tjetër lidhet me faktin se arkitektura e utmp lejon përdoruesit lokalë të kryejnë sulme DoS, duke sjellë acarim të funksionimit të shërbimit utmp përmes manipulimeve me bllokadat në skedar, çka e bën të paqartë se përmbajtja e utmp reflekton gjendjen reale në sistem. Për të menaxhuar qasjen në utmp është propozuar përdorimi i një procesi shtesë në sfond, por për detyra të tilla tashmë ekziston procesi systemd-logind dhe nisja e një procesi tjetër të specializuar nuk është e arsyeshme (aplikacionet do të duhet t'i kalojnë të dhënat në të njëjtën kohë në dy trajtues).
MegjithatĂ«, edhe me zgjidhjen e problemit me sulmet DoS, pĂ«rmbajtja e utmp mbetet vetĂ«m informacionale, pa garantuar reflektimin e realitetit. PĂ«r shembull, emulatorĂ«t e ndryshĂ«m dhe muxer qĂ« pĂ«rdoren pĂ«r terminale reflektojnĂ« gjendjen e tyre ndrysheânisja e pesĂ« terminaleve GNOME do tĂ« rezultojĂ« nĂ« reflektimin nĂ« utmp tĂ« njĂ« pĂ«rdoruesi, ndĂ«rsa nisja e pesĂ« terminaleve konsole ose xterm nĂ« KDE do tĂ« rezultojĂ« nĂ« gjashtĂ«. Po ashtu, sjellja ndryshon mes screen dhe tmux; nĂ« rastin e parĂ«, çdo seancĂ« llogaritet si njĂ« pĂ«rdorues i veçantĂ«, ndĂ«rsa nĂ« tĂ« dytin reflektohet vetĂ«m njĂ« pĂ«rdorues pĂ«r tĂ« gjitha seancat.
Si pasojë, si një 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ë drejtohen te utmp, të ndalet regjistrimi në utmp. Për të zëvendësuar wtmp, propozohet përgatitja e ndërfaqeve programore për regjistrimin dhe leximin e informacionit rreth përdoruesve nëpërmjet systemd-journald. Funksionet e nevojshme për ofrimin e të dhënave zëvendësuese të utmp përmes libsystemd, duke përdorur API sd-login.h ose përmes DBUS, janë përfshirë tashmë në bazën e kodit të këtyre versioneve të ardhshme systemd 254.
Burimi: opennet.ru
