Өмнө нь SUSE LINUX Enterprise Server төслийг 10 жил удирдаж байсан SUSE (Ирээдүйн технологийн баг, openSUSE MicroOS болон SLE Micro хөгжүүлдэг)-ийн Ирээдүйн технологийн багийн ахлагч Торстен Кукук /var/run/utmp файлыг устгахыг санал болгов. Glibc дахь Y2038 асуудлыг бүрэн шийдвэрлэхийн тулд түгээлтүүд. utmp, wtmp, lastlog ашигладаг бүх программыг systemd-logind ашиглан хэрэглэгчдийн жагсаалтыг авах руу шилжүүлэхийг санал болгож байна.
19 оны 2038-р сарын 32-нд 64 битийн time_t төрлөөр тодорхойлсон эрин цагийн тоолуур халих болно. Glibc-д 32 битийн time_t төрлийг нэвтрүүлсэн хэдий ч 64 битийн хэрэглэгчийн орон зайн програмуудтай нийцтэй байхын тулд 32 битийн time_t төрлийг зарим тохиолдолд 32 битийн платформ дээр ашигладаг хэвээр байна. Ийм тохиолдлын нэг бол системд нэвтэрсэн хэрэглэгчдийн мэдээллийг хадгалдаг /var/run/utmp файл юм. utmp дахь цагийн талбарыг XNUMX битийн time_t утгыг ашиглан тохируулсан.
Цаг хугацаа өнгөрөхөд utmp дахь талбарыг 32-битээс 64-бит төрөл болгон өөрчлөх нь ажиллахгүй, учир нь энэ нь Glibc ABI-г өөрчлөх болно (login(), getutid() болон utmpname() гэх мэт функцүүдэд төрөл өөрчлөгдөнө) w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm дэлгэцийн менежер, emacs, openssh, qemu, samba, rsyslog гэх мэт utmp ашигладаг програмуудтай нийцтэй байдлыг эвдэх. Боломжит бэрхшээлүүд, хөдөлмөр зүтгэлийн улмаас utmp дахь time_t төрлийн битийн уртыг солих санааг Glibc-ийн хөгжүүлэгчид няцаасан. Үүнтэй ижил шалтгаанаар 64 битийн нэмэлт цагийн талбар нэмэхийн тулд utmp бүтэц дэх боломжтой зайг ашиглах сонголтыг хассан.
Нэмж дурдахад, utmp дахь төрлийн битийн гүнийг өөрчлөх нь одоо байгаа бусад асуудлуудыг шийдэхгүй бөгөөд би үүнийг арилгахыг хүсч байна. Жишээлбэл, utmp руу бичих нь тусгай зөвшөөрөл шаарддаг бөгөөд энэ нь процессуудад нэмэлт эрх олгохыг шаарддаг. Өөр нэг асуудал бол utmp архитектур нь орон нутгийн хэрэглэгчдэд файлын түгжээг ашиглан utmp үйлчилгээг эвдэх DoS халдлага хийх боломжийг олгодог бөгөөд utmp-ийн агуулга нь систем дэх бодит байдлыг харуулж байгаа гэдэгт итгэлтэй байх боломжгүй болгодог. utmp-д хандах хандалтыг зохицуулах нэмэлт суурь процессыг ашиглахыг санал болгосон боловч ийм даалгаврын хувьд системд нэвтрэх процесс аль хэдийн байгаа бөгөөд өөр тусгай процессыг эхлүүлэхийг зөвлөдөггүй (програмууд нь хоёр зохицуулагч руу нэгэн зэрэг өгөгдөл дамжуулах шаардлагатай болно) .
Үүний зэрэгцээ, DoS халдлагын асуудлыг шийдэж байсан ч utmp-ийн агуулга нь бодит байдлын тусгалыг баталгаажуулахгүй зөвхөн мэдээллийн шинж чанартай хэвээр байна. Жишээлбэл, өөр өөр терминал эмуляторууд болон мультиплексорууд нь тэдний төлөвийг өөр өөрөөр тусгадаг - таван GNOME терминал ажиллуулах нь нэг хэрэглэгчийг utmp-д тусгахад хүргэдэг бол KDE-д таван konsole эсвэл xterm терминал ажиллуулахад зургаа нь гарах болно. Үүний нэгэн адил, дэлгэц болон tmux-ийн үйлдэл нь ялгаатай бөгөөд эхний тохиолдолд сесс бүрийг тусдаа хэрэглэгч гэж тооцдог бол хоёр дахь тохиолдолд зөвхөн нэг хэрэглэгчийг бүх сешнүүдэд тусгасан болно.
Үүний үр дүнд, хамгийн энгийн шийдэл болгон, аль хэдийн байгаа системd-нэвтрэх үйлчилгээг ашиглахын тулд бүх програмуудыг шилжүүлэхийг санал болгож байна, utmp руу нэвтрэх бодит програм байхгүй бол utmp руу бичихээ боль. Wtmp-ийг солихын тулд systemd-journald ашиглан хэрэглэгчдийн талаарх мэдээллийг бичих, уншихад API бэлтгэхийг санал болгож байна. Systemd 254-ийн дараагийн хувилбарын кодын бааз нь sd-login.h API эсвэл DBUS-ээр дамжуулан libsystemd-ээр дамжуулан utmp өгөгдлийг солих шаардлагатай функцуудыг агуулж байна.
Эх сурвалж: opennet.ru