Thorsten Kukuk, gvidanto de la Future Technology Team ĉe SUSE (Future Technology Team, evoluigas openSUSE MicroOS kaj SLE Micro), kiu antaŭe gvidis la projekton SUSE LINUX Enterprise Server dum 10 jaroj, sugestis forigi la /var/run/utmp-dosieron en distribuoj por plene trakti la problemon Y2038 en Glibc. Ĉiuj aplikaĵoj uzantaj utmp, wtmp, kaj lastlog estas proponitaj por esti movitaj por ricevi liston de uzantoj per systemd-logind.
La 19-an de januaro 2038, la epoktempaj nombriloj specifitaj per la 32-bita time_t-tipo superfluos. En Glibc, malgraŭ la enkonduko de la 64-bita time_t-tipo, por konservi kongruon kun 32-bita uzant-spacaj aplikoj, la 64-bita time_t-tipo daŭre estas uzita en kelkaj kazoj sur 32-bitaj platformoj. Unu tia kazo estas la /var/run/utmp-dosiero, kiu konservas datumojn pri la uzantoj nuntempe ensalutitajn en la sistemon. La tempokampo en utmp estas agordita uzante 32-bitan time_t valoron.
Simple ŝanĝi kampon en utmp laŭlonge de la tempo de 32-bita al 64-bita tipo ne funkcios, ĉar ĉi tio ŝanĝos la Glibc-ABI (la tipo ŝanĝiĝos en funkcioj kiel ensalutu(), getutid() kaj utmpname()) kaj rompas kongruon kun aplikaĵoj kiuj uzas utmp, inkluzive de w, who, uptime, ensaluto, su, sudo, useradd, systemd, sysvinit, tcsh, xterm ekranmanaĝeroj, emacs, openssh, qemu, samba, rsyslog, ktp. Pro la abundo de eblaj faŭltoj kaj peneco, la ideo anstataŭigi la bitlongon de la time_t-tipo en utmp estis malakceptita de la programistoj de Glibc. Pro la sama kialo, la opcio uzi la disponeblan spacon en la utmp-strukturo por aldoni plian 64-bitan tempokampon estis forigita.
Krome, ŝanĝi la bitprofundon de la tipo en utmp ne solvas aliajn ekzistantajn problemojn, kiujn mi ankaŭ ŝatus forigi. Ekzemple, skribi al utmp postulas specialajn permesojn, kio postulas kromajn privilegiojn doni al procezoj. Alia problemo estas, ke la utmp-arkitekturo permesas al lokaj uzantoj fari DoS-atakojn, kiuj rompas la utmp-servon per manipulado de dosieraj seruroj, ne eblas certigi, ke la enhavo de utmp reflektas la realan staton en la sistemo. Oni proponis uzi plian fonan procezon por trakti aliron al utmp, sed por tiaj taskoj jam ekzistas systemd-logind-procezo kaj komenci alian specialan procezon ne estas konsilinda (aplikoj devos transdoni datumojn al du pritraktiloj samtempe) .
Samtempe, eĉ kiam oni solvas la problemon kun DoS-atakoj, la enhavo de utmp restas nur informa, ne garantiante spegulbildon de la realo. Ekzemple, malsamaj finaj emuliloj kaj multipleksiloj reflektas sian staton alimaniere - ruli kvin GNOME-terminalojn rezultigos unu uzanton esti reflektita en utmp, dum ruli kvin konsole aŭ xterm-terminalojn en KDE rezultigos ses. Simile, la konduto de ekrano kaj tmux malsamas, en la unua kazo ĉiu sesio estas kalkulita kiel aparta uzanto, kaj en la dua nur unu uzanto estas reflektita por ĉiuj sesioj.
Kiel rezulto, kiel la plej simpla solvo, oni proponas translokigi ĉiujn aplikaĵojn por uzi la jam ekzistantan alternativan servon systemd-logind kaj, post kiam ne ekzistas realaj programoj alirantaj utmp, ĉesu skribi al utmp. Por anstataŭigi wtmp, estas proponite prepari APIojn por skribi kaj legi informojn pri uzantoj uzante systemd-journald. La kodbazo por la venonta eldono de systemd 254 jam inkluzivas la necesajn funkciojn por provizi anstataŭajn utmp-datumojn per libsystemd uzante la sd-login.h API aŭ per DBUS.
fonto: opennet.ru