Thorsten Kukuk, pimpinan Tim Teknologi Masa Depan ing SUSE (Tim Teknologi Masa Depan, ngembangake openSUSE MicroOS lan SLE Micro), sing sadurunge mimpin proyek SUSE LINUX Enterprise Server suwene 10 taun, nyaranake mbusak file /var/run/utmp ing distribusi kanggo ngrampungake masalah Y2038 ing Glibc. Kabeh aplikasi sing nggunakake utmp, wtmp, lan lastlog diusulake supaya dipindhah menyang dhaptar pangguna nggunakake systemd-logind.
Tanggal 19 Januari 2038, konter jaman sing ditetepake kanthi jinis time_t 32-bit bakal kebanjiran. Ing Glibc, senadyan introduksi jinis time_t 64-bit, kanggo njaga kompatibilitas karo aplikasi ruang pangguna 32-bit, jinis time_t 64-bit terus digunakake ing sawetara kasus ing platform 32-bit. Salah sawijining kasus yaiku file /var/run/utmp, sing nyimpen data babagan pangguna sing saiki mlebu ing sistem kasebut. Kolom wektu ing utmp disetel nggunakake nilai time_t 32-bit.
Mung ngganti lapangan ing utmp saka jinis 32-dicokot kanggo jinis 64-dicokot liwat wektu ora bisa, amarga iki bakal ngganti Glibc ABI (jinis bakal ngganti ing fungsi kaya login (), getutid () lan utmpname () ) lan break kompatibilitas karo aplikasi sing nggunakake utmp, kalebu w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, manajer tampilan xterm, emacs, openssh, qemu, samba, rsyslog, lsp. Amarga akeh kemungkinan pitfalls lan laboriousness, ide kanggo ngganti dawa bit saka jinis time_t ing utmp ditolak dening pangembang Glibc. Kanggo alasan sing padha, pilihan kanggo nggunakake ruang sing kasedhiya ing struktur utmp kanggo nambah lapangan wektu 64-bit tambahan dicopot.
Kajaba iku, ngganti ambane bit saka jinis ing utmp ora ngatasi masalah liyane sing wis ana, sing aku uga pengin nyingkirake. Contone, nulis menyang utmp mbutuhake ijin khusus, sing mbutuhake hak istimewa tambahan sing diwenehake marang proses. Masalah liyane yaiku arsitektur utmp ngidini pangguna lokal nindakake serangan DoS sing ngrusak layanan utmp liwat manipulasi kunci file, saengga ora bisa mesthekake yen isi utmp nggambarake kahanan nyata ing sistem kasebut. Disaranake nggunakake proses latar mburi tambahan kanggo nangani akses menyang utmp, nanging kanggo tugas kasebut wis ana proses login systemd lan ora dianjurake kanggo miwiti proses khusus liyane (aplikasi kudu nransfer data menyang loro panangan ing wektu sing padha) .
Ing wektu sing padha, sanajan ngrampungake masalah karo serangan DoS, isi utmp tetep mung informasi, ora njamin bayangan kasunyatan. Contone, emulator terminal lan multiplexer beda nggambarake negarane kanthi beda - mlaku limang terminal GNOME bakal nyebabake siji pangguna dibayangke ing utmp, nalika mbukak limang terminal konsole utawa xterm ing KDE bakal ngasilake enem. Kajaba iku, prilaku layar lan tmux beda-beda, ing kasus sing sepisanan saben sesi diitung minangka pangguna sing kapisah, lan ing kaloro mung siji pangguna sing dibayangke kanggo kabeh sesi.
AkibatΓ©, minangka solusi sing paling gampang, disaranake nransfer kabeh aplikasi kanggo nggunakake layanan log-login alternatif sing wis ana lan, sawise ora ana program nyata sing ngakses utmp, mandheg nulis menyang utmp. Kanggo ngganti wtmp, disaranake nyiyapake API kanggo nulis lan maca informasi babagan pangguna nggunakake systemd-journald. Basis kode kanggo release sabanjure systemd 254 wis kalebu fungsi sing dibutuhake kanggo nyedhiyakake data utmp panggantos liwat libsystemd nggunakake sd-login.h API utawa liwat DBUS.
Source: opennet.ru