Thorsten Kukuk, SUSEko Etorkizuneko Teknologia Taldeko liderrak (Etorkizuneko Teknologia Taldea, openSUSE MicroOS eta SLE Micro garatzen ditu), aurretik SUSE LINUX Enterprise Server proiektua zuzendu zuenak 10 urtez, /var/run/utmp fitxategia kentzea proposatu zuen. banaketak Glibc-en Y2038 arazoari guztiz aurre egiteko. utmp, wtmp eta lastlog erabiltzen dituzten aplikazio guztiak systemd-logind erabiliz erabiltzaileen zerrenda bat lortzera eramatea proposatzen da.
19ko urtarrilaren 2038an, 32 biteko time_t motak zehaztutako denbora-kontagailuak gainezka egingo dira. Glibc-en, 64 biteko time_t mota sartu arren, 32 biteko erabiltzaile-espazioko aplikazioekin bateragarritasuna mantentzeko, 64 biteko time_t mota oraindik ere erabiltzen da kasu batzuetan 32 biteko plataformetan. Kasu horietako bat /var/run/utmp fitxategia da, sisteman une honetan saioa hasita dauden erabiltzaileei buruzko datuak gordetzen dituena. Utmp-en denbora eremua 32 biteko time_t balio bat erabiliz ezartzen da.
Denboran zehar utmp-ko eremu bat 32 biteko motatik 64 biteko mota batera aldatzeak ez du funtzionatuko, honek Glibc ABI aldatuko baitu (mota aldatuko da login(), getutid() eta utmpname() bezalako funtzioetan. ) eta utmp erabiltzen duten aplikazioekin bateragarritasuna hautsi, w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, etab. Arazo posibleen eta neketsuen ugaritasuna dela eta, time_t motaren bit luzera utmp-en ordezkatzeko ideia baztertu zuten Glibc-en garatzaileek. Arrazoi beragatik, utmp egituran erabilgarri dagoen espazioa 64 biteko denbora eremu gehigarri bat gehitzeko aukera kendu zen.
Gainera, utmp-en motaren bit-sakonera aldatzeak ez ditu lehendik dauden beste arazo batzuk konpontzen, nik ere kentzea gustatuko litzaidake. Adibidez, utmp-ra idazteak baimen bereziak behar ditu, eta horrek pribilegio gehigarriak eman behar dizkie prozesuei. Beste arazo bat da utmp arkitekturak tokiko erabiltzaileei utmp zerbitzua apurtzen duten DoS erasoak egiteko aukera ematen diela fitxategien blokeoen manipulazioaren bidez, eta ezinezkoa da utmp-en edukiak sistemako egoera erreala islatzen duela ziurtatzea. Utmp-rako sarbidea kudeatzeko atzeko planoko prozesu gehigarri bat erabiltzea proposatu zen, baina horrelako zereginetarako dagoeneko systemd-logind prozesu bat dago eta beste prozesu espezializatu bat abiaraztea ez da komeni (aplikazioek bi kudeatzailetara transferitu beharko dituzte datuak aldi berean). .
Aldi berean, DoS erasoen arazoa konpontzen denean ere, utmp-en edukia informaziozkoa baino ez da izaten, errealitatearen islarik ez duela bermatzen. Esate baterako, terminal emuladore eta multiplexagailu ezberdinek beren egoera ezberdin islatzen dute - GNOME terminalek bost terminal exekutatuta erabiltzaile bat utmp-en islatuko da, eta bost konsole edo xterm terminal KDEn exekutatzen diren bitartean sei. Era berean, pantailaren eta tmux-en portaera desberdina da, lehenengo kasuan saio bakoitza erabiltzaile bereizi gisa zenbatzen da, eta bigarrenean erabiltzaile bakarra islatzen da saio guztietarako.
Ondorioz, irtenbiderik errazena denez, aplikazio guztiak transferitzea proposatzen da lehendik dagoen systemd-logind zerbitzu alternatiboa erabiltzeko eta, utmp-ra sartzen diren benetako programarik ez dagoenean, utmp-en idazteari uztea. wtmp ordezkatzeko, systemd-journald erabiliz erabiltzaileei buruzko informazioa idazteko eta irakurtzeko APIak prestatzea proposatzen da. Systemd 254-ren hurrengo bertsiorako kode-baseak ordezko utmp datuak libsystemd-en bidez sd-login.h APIa erabiliz edo DBUS bidez emateko beharrezko funtzioak biltzen ditu jada.
Iturria: opennet.ru