បានស្នើឱ្យឈប់ប្រើ utmp ដើម្បីបំបាត់ Glibc នៃបញ្ហា Y2038

Thorsten Kukuk អ្នកដឹកនាំក្រុមអភិវឌ្ឍន៍បច្ចេកវិទ្យានាពេលអនាគតនៅ SUSE (Future Technology Team បង្កើត openSUSE MicroOS និង SLE Micro) ដែលពីមុនបានដឹកនាំគម្រោង SUSE LINUX Enterprise Server អស់រយៈពេល 10 ឆ្នាំបានស្នើឱ្យកម្ចាត់ឯកសារ /var/run/utmp នៅក្នុងការចែកចាយដើម្បីដោះស្រាយបញ្ហាឆ្នាំ 2038 យ៉ាងពេញលេញនៅក្នុង Glibc ។ កម្មវិធីទាំងអស់ដែលប្រើ utmp, wtmp និង lastlog ត្រូវបានស្នើឱ្យបម្លែងទៅជាការទទួលបានបញ្ជីអ្នកប្រើប្រាស់ដោយប្រើ systemd-login ។

នៅថ្ងៃទី 19 ខែមករា ឆ្នាំ 2038 ការរាប់ពេលវេលា epochal ដែលបានបញ្ជាក់ដោយប្រភេទ time_t 32-bit នឹងលើស។ Glibc ទោះបីជាបានណែនាំប្រភេទ time_t 64 ប៊ីតក៏ដោយ ក៏នៅតែបន្តប្រើប្រភេទ time_t 32 ប៊ីត ក្នុងករណីខ្លះនៅលើវេទិកា 64 ប៊ីត ដើម្បីរក្សាភាពឆបគ្នាជាមួយកម្មវិធីចន្លោះអ្នកប្រើប្រាស់ 32 ប៊ីត។ ករណីមួយគឺឯកសារ /var/run/utmp ដែលរក្សាទុកទិន្នន័យអំពីអ្នកប្រើប្រាស់ដែលបានចូលប្រព័ន្ធនាពេលបច្ចុប្បន្ន។ វាលពេលវេលានៅក្នុង utmp ត្រូវបានបញ្ជាក់ដោយប្រើតម្លៃ time_t 32 ប៊ីត។

គ្រាន់តែជំនួសវាលពេលវេលានៅក្នុង utmp ពី 32 ប៊ីតទៅប្រភេទ 64 ប៊ីតនឹងមិនដំណើរការទេព្រោះវានឹងនាំឱ្យមានការផ្លាស់ប្តូរនៅក្នុង Glibc ABI (ប្រភេទនឹងផ្លាស់ប្តូរមុខងារដូចជា login(), getutid() និង utmpname ()) និងបំបែកភាពឆបគ្នាជាមួយកម្មវិធីដែលប្រើ utmp រួមទាំង w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog ជាដើម។ ដោយសារតែភាពសម្បូរបែបនៃបញ្ហាដែលអាចកើតមាន និងភាពស្មុគស្មាញ គំនិតនៃការជំនួសប្រភេទ time_t នៅក្នុង utmp ត្រូវបានច្រានចោលដោយអ្នកអភិវឌ្ឍន៍ Glibc ។ សម្រាប់ហេតុផលដូចគ្នា ជម្រើសនៃការប្រើប្រាស់ទំហំទំនេរដែលមាននៅក្នុងរចនាសម្ព័ន្ធ utmp ដើម្បីបន្ថែមវាលពេលវេលា 64 ប៊ីតបន្ថែមត្រូវបានលុបចោល។

លើសពីនេះទៀត ការផ្លាស់ប្តូរប្រភេទ bit depth នៅក្នុង utmp មិនដោះស្រាយបញ្ហាដែលមានស្រាប់ផ្សេងទៀត ដែលខ្ញុំក៏ចង់កម្ចាត់ដែរ។ ឧទាហរណ៍ ការសរសេរទៅ utmp ទាមទារការអនុញ្ញាតពិសេស ដែលទាមទារដំណើរការដើម្បីទទួលបានសិទ្ធិបន្ថែម។ បញ្ហាមួយទៀតគឺថាស្ថាបត្យកម្ម utmp អនុញ្ញាតឱ្យអ្នកប្រើប្រាស់ក្នុងស្រុកអនុវត្តការវាយប្រហារ DoS ដែលនាំឱ្យមានការរំខានដល់សេវាកម្ម utmp តាមរយៈការរៀបចំការចាក់សោឯកសារ ដែលធ្វើឱ្យវាមិនអាចប្រាកដថាខ្លឹមសារនៃ utmp ឆ្លុះបញ្ចាំងពីស្ថានភាពពិតនៅក្នុងប្រព័ន្ធ។ វាត្រូវបានស្នើឱ្យប្រើដំណើរការផ្ទៃខាងក្រោយបន្ថែមដើម្បីគ្រប់គ្រងការចូលប្រើ utmp ប៉ុន្តែសម្រាប់កិច្ចការបែបនេះមានដំណើរការ systemd-login រួចហើយ ហើយការចាប់ផ្តើមដំណើរការឯកទេសផ្សេងទៀតមិនត្រូវបានណែនាំទេ (កម្មវិធីនឹងត្រូវផ្ទេរទិន្នន័យទៅអ្នកដោះស្រាយពីរនាក់ក្នុងពេលដំណាលគ្នា) ។

ក្នុងពេលជាមួយគ្នានេះ សូម្បីតែនៅពេលដោះស្រាយបញ្ហាជាមួយនឹងការវាយប្រហារ DoS ក៏ដោយ ខ្លឹមសារនៃ utmp នៅតែមានព័ត៌មានតែប៉ុណ្ណោះ ហើយមិនធានាការឆ្លុះបញ្ចាំងពីការពិតនោះទេ។ ឧទាហរណ៍ កម្មវិធីត្រាប់តាមផ្សេងគ្នា និងឧបករណ៍ពហុគុណស្ថានីយឆ្លុះបញ្ចាំងពីស្ថានភាពរបស់វាខុសគ្នា - ការបើកដំណើរការស្ថានីយ GNOME ចំនួនប្រាំនឹងនាំឱ្យអ្នកប្រើប្រាស់ម្នាក់ត្រូវបានឆ្លុះបញ្ចាំងនៅក្នុង utmp ហើយការបើកដំណើរការស្ថានីយកុងសូល ឬ xterm ចំនួនប្រាំនៅក្នុង KDE នឹងមានលទ្ធផលប្រាំមួយ។ ឥរិយាបទនៃអេក្រង់ និង tmux គឺខុសគ្នាប្រហាក់ប្រហែលគ្នា៖ ក្នុងករណីទីមួយ វគ្គនីមួយៗត្រូវបានរាប់ជាអ្នកប្រើប្រាស់ដាច់ដោយឡែក ហើយនៅក្នុងទីពីរ អ្នកប្រើប្រាស់តែមួយប៉ុណ្ណោះដែលត្រូវបានឆ្លុះបញ្ចាំងសម្រាប់វគ្គទាំងអស់។

ជាលទ្ធផល ជាដំណោះស្រាយដ៏សាមញ្ញបំផុត វាត្រូវបានស្នើឱ្យផ្ទេរកម្មវិធីទាំងអស់ដើម្បីប្រើប្រាស់សេវាចូលប្រព័ន្ធដែលមានស្រាប់ហើយបន្ទាប់ពីមិនមានកម្មវិធីបច្ចុប្បន្នចូលប្រើ utmp បញ្ឈប់ការថតទៅ utmp ។ ដើម្បីជំនួស wtmp វាត្រូវបានស្នើឡើងដើម្បីរៀបចំចំណុចប្រទាក់កម្មវិធីសម្រាប់ការសរសេរ និងអានព័ត៌មានអំពីអ្នកប្រើប្រាស់ដោយប្រើ systemd-journald ។ មូលដ្ឋានកូដសម្រាប់ការចេញផ្សាយបន្ទាប់នៃ systemd 254 រួមបញ្ចូលមុខងារចាំបាច់រួចហើយដើម្បីផ្តល់ទិន្នន័យជំនួស utmp តាមរយៈ libsystemd ដោយប្រើ sd-login.h API ឬតាមរយៈ DBUS ។

ប្រភព: opennet.ru