Upang alisin ang Glibc sa 2038 na problema, iminungkahi na ihinto ang paggamit ng utmp

Si Thorsten Kukuk, pinuno ng pangkat ng pagpapaunlad ng teknolohiya sa hinaharap sa SUSE (Future Technology Team, ay bumuo ng openSUSE MicroOS at SLE Micro), na dating pinamunuan ang proyekto ng SUSE LINUX Enterprise Server sa loob ng 10 taon, ay nagmungkahi na alisin ang /var/run/utmp file sa mga pamamahagi upang ganap na matugunan ang 2038 na problema sa Glibc. Ang lahat ng mga application na gumagamit ng utmp, wtmp at lastlog ay iminungkahi na ma-convert sa pagkuha ng isang listahan ng mga gumagamit gamit ang systemd-logind.

Sa Enero 19, 2038, aapaw ang mga epochal time counter na tinukoy ng 32-bit time_t type. Si Glibc, sa kabila ng pagpapakilala ng 64-bit na time_t type, ay patuloy na gumagamit ng 32-bit time_t type sa ilang mga kaso sa 64-bit na mga platform upang mapanatili ang pagiging tugma sa 32-bit na user space na mga application. Ang isang ganoong kaso ay ang /var/run/utmp file, na nag-iimbak ng data tungkol sa mga user na kasalukuyang naka-log in sa system. Tinukoy ang field ng oras sa utmp gamit ang 32-bit na time_t value.

Ang pagpapalit lang ng time field sa utmp mula sa 32-bit hanggang sa 64-bit na uri ay hindi gagana, dahil hahantong ito sa pagbabago sa Glibc ABI (magbabago ang uri sa mga function tulad ng login(), getutid() at utmpname ()) at paglabag sa compatibility sa mga application na gumagamit ng utmp, kabilang ang w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, atbp. Dahil sa kasaganaan ng mga posibleng pitfalls at pagiging kumplikado, ang ideya ng pagpapalit ng time_t type sa utmp ay tinanggihan ng mga developer ng Glibc. Para sa parehong dahilan, ang opsyon ng paggamit ng magagamit na libreng espasyo sa istraktura ng utmp upang magdagdag ng karagdagang 64-bit na field ng oras ay itinapon.

Bilang karagdagan, ang pagbabago ng uri ng bit depth sa utmp ay hindi malulutas ang iba pang umiiral na mga problema, na gusto ko ring alisin. Halimbawa, ang pagsusulat sa utmp ay nangangailangan ng mga espesyal na karapatan, na nangangailangan ng mga proseso na mabigyan ng karagdagang mga pribilehiyo. Ang isa pang problema ay ang arkitektura ng utmp ay nagpapahintulot sa mga lokal na gumagamit na magsagawa ng mga pag-atake ng DoS, na humahantong sa pagkagambala sa serbisyo ng utmp sa pamamagitan ng pagmamanipula ng mga lock ng file, na ginagawang imposibleng matiyak na ang mga nilalaman ng utmp ay sumasalamin sa tunay na estado sa system. Iminungkahi na gumamit ng karagdagang proseso sa background upang mahawakan ang pag-access sa utmp, ngunit para sa mga naturang gawain mayroon nang isang systemd-logind na proseso at ang paglulunsad ng isa pang dalubhasang proseso ay hindi ipinapayong (ang mga application ay kailangang maglipat ng data sa dalawang handler nang sabay-sabay).

Kasabay nito, kahit na nilutas ang problema sa mga pag-atake ng DoS, ang mga nilalaman ng utmp ay nananatiling impormasyon lamang at hindi ginagarantiyahan ang isang pagmuni-muni ng katotohanan. Halimbawa, ang iba't ibang mga emulator at terminal multiplexer ay nagpapakita ng kanilang estado nang iba - ang paglulunsad ng limang GNOME terminal ay magreresulta sa isang user na makikita sa utmp, at ang paglulunsad ng limang konsole o xterm terminal sa KDE ay magreresulta sa anim. Magkaiba ang gawi ng screen at tmux: sa unang kaso, ang bawat session ay binibilang bilang isang hiwalay na user, at sa pangalawa, isang user lang ang makikita para sa lahat ng session.

Bilang resulta, bilang pinakasimpleng solusyon, iminungkahi na ilipat ang lahat ng mga application upang magamit ang umiiral nang alternatibong serbisyo ng systemd-logind at, pagkatapos na walang kasalukuyang mga programang nag-a-access sa utmp, ihinto ang pagre-record sa utmp. Upang palitan ang wtmp, iminungkahi na maghanda ng mga interface ng software para sa pagsusulat at pagbabasa ng impormasyon tungkol sa mga gumagamit na gumagamit ng systemd-journald. Kasama na sa codebase para sa susunod na release ng systemd 254 ang kinakailangang functionality para magbigay ng utmp replacement data sa pamamagitan ng libsystemd gamit ang sd-login.h API o sa pamamagitan ng DBUS.

Pinagmulan: opennet.ru

Magdagdag ng komento