SUSE லினக்ஸ் எண்டர்பிரைஸ் சர்வர் திட்டத்தை 10 ஆண்டுகளாக வழிநடத்திய SUSE இன் எதிர்கால தொழில்நுட்பக் குழுவின் தலைவரான தோர்ஸ்டன் குக்குக் (openSUSE MicroOS மற்றும் SLE Micro இன் டெவலப்பர்), Glibc Year 2038 சிக்கலை முழுமையாகத் தீர்க்க விநியோகங்களிலிருந்து /var/run/utmp கோப்பை நீக்க முன்மொழிந்தார். utmp, wtmp மற்றும் lastlog ஐப் பயன்படுத்தும் அனைத்து பயன்பாடுகளும் systemd-logind ஐப் பயன்படுத்தி பயனர் பட்டியல்களை மீட்டெடுப்பதற்கு நகர்த்த முன்மொழியப்பட்டுள்ளன.
ஜனவரி 19, 2038 அன்று, 32-பிட் டைம்_டி வகையால் குறிப்பிடப்பட்ட எபோகல் நேர கவுண்டர்கள் நிரம்பி வழியும். 64-பிட் டைம்_டி வகை அறிமுகப்படுத்தப்பட்ட போதிலும், 32-பிட் பயனர்-இட பயன்பாடுகளுடன் இணக்கத்தன்மையைப் பராமரிக்க 64-பிட் தளங்களில் சில சந்தர்ப்பங்களில் 32-பிட் டைம்_டி வகையை Glibc நூலகம் தொடர்ந்து பயன்படுத்துகிறது. அத்தகைய ஒரு நிகழ்வு /var/run/utmp கோப்பு, இது தற்போது கணினியில் உள்நுழைந்துள்ள பயனர்கள் பற்றிய தரவைச் சேமிக்கிறது. utmp இல் உள்ள நேரப் புலம் 32-பிட் டைம்_டி மதிப்பைப் பயன்படுத்தி குறிப்பிடப்படுகிறது.
utmp இல் 32-பிட் நேர புலத்தை 64-பிட் வகையுடன் மாற்றுவது சாத்தியமில்லை, ஏனெனில் இது Glibc ABI ஐ மாற்றும் (login(), getutid(), மற்றும் utmpname() போன்ற செயல்பாடுகளில் உள்ள வகை மாறும்) மற்றும் w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog மற்றும் பிறவற்றை உள்ளடக்கிய utmp ஐப் பயன்படுத்தும் பயன்பாடுகளுடன் இணக்கத்தன்மையை உடைக்கும். ஏராளமான சாத்தியமான சிக்கல்கள் மற்றும் சிக்கலான தன்மை காரணமாக, utmp இல் time_t வகையை மாற்றும் யோசனை Glibc டெவலப்பர்களால் நிராகரிக்கப்பட்டது. அதே காரணத்திற்காக, utmp கட்டமைப்பில் கிடைக்கும் இலவச இடத்தைப் பயன்படுத்தி கூடுதல் 64-பிட் நேர புலத்தைச் சேர்க்கும் விருப்பம் நிராகரிக்கப்பட்டது.
மேலும், utmp கோப்பு வகையின் பிட் ஆழத்தை மாற்றுவது, ஏற்கனவே உள்ள பிற சிக்கல்களைத் தீர்க்காது, அவை தீர்க்க விரும்பத்தக்கதாக இருக்கும். எடுத்துக்காட்டாக, utmp க்கு எழுதுவதற்கு சிறப்பு அனுமதிகள் தேவை, இதற்கு செயல்முறைகளுக்கு கூடுதல் சலுகைகள் வழங்கப்பட வேண்டும். மற்றொரு சிக்கல் என்னவென்றால், utmp கட்டமைப்பு உள்ளூர் பயனர்கள் கோப்பு பூட்டுகளை கையாளுவதன் மூலம் utmp சேவையை சீர்குலைக்கும் DoS தாக்குதல்களைச் செய்ய அனுமதிக்கிறது, இதனால் utmp உள்ளடக்கங்கள் உண்மையான கணினி நிலையை பிரதிபலிக்கின்றன என்பதை உறுதிப்படுத்துவது சாத்தியமற்றது. utmp க்கான அணுகலைக் கையாள கூடுதல் பின்னணி செயல்முறையைப் பயன்படுத்துவது முன்மொழியப்பட்டது, ஆனால் systemd-logind செயல்முறை ஏற்கனவே அத்தகைய பணிகளுக்கு உள்ளது, மேலும் மற்றொரு சிறப்பு செயல்முறையைத் தொடங்குவது நடைமுறைக்கு மாறானது (பயன்பாடுகள் ஒரே நேரத்தில் இரண்டு கையாளுபவர்களுக்கு தரவை மாற்ற வேண்டும்).
DoS தாக்குதல் சிக்கல் தீர்க்கப்பட்டாலும் கூட, utmp உள்ளடக்கங்கள் தகவல் நோக்கங்களுக்காக மட்டுமே இருக்கும், மேலும் அவை உண்மையான யதார்த்தத்தை பிரதிபலிக்கும் என்பதற்கு உத்தரவாதம் இல்லை. எடுத்துக்காட்டாக, வெவ்வேறு முனைய முன்மாதிரிகள் மற்றும் மல்டிபிளெக்சர்கள் அவற்றின் நிலையை வித்தியாசமாகக் காட்டுகின்றன: ஐந்து GNOME முனையங்களைத் தொடங்குவது ஒரு பயனரை utmp இல் காண்பிக்கும், அதே நேரத்தில் KDE இல் ஐந்து konsole அல்லது xterm முனையங்களைத் தொடங்குவது ஆறுக்கு வழிவகுக்கும். இதேபோல், திரை மற்றும் tmux வித்தியாசமாக நடந்து கொள்கின்றன: முந்தையதில், ஒவ்வொரு அமர்வும் ஒரு தனி பயனராகக் கணக்கிடப்படும், அதே சமயம் பிந்தையதில், அனைத்து அமர்வுகளிலும் ஒரு பயனர் மட்டுமே காட்டப்படுவார்.
இறுதியாக, முன்மொழியப்பட்ட எளிய தீர்வு, அனைத்து பயன்பாடுகளையும் ஏற்கனவே உள்ள மாற்று சேவையான systemd-logind க்கு நகர்த்துவதாகும், மேலும், utmp ஐ அணுகும் பொருத்தமான நிரல்கள் இல்லாதவுடன், utmp க்கு எழுதுவதை நிறுத்துங்கள். wtmp ஐ மாற்ற, systemd-journald ஐப் பயன்படுத்தி பயனர் தகவல்களை எழுதுவதற்கும் படிப்பதற்கும் API களை உருவாக்க முன்மொழியப்பட்டுள்ளது. systemd 254 இன் அடுத்த வெளியீட்டிற்கான குறியீட்டுத் தளம் ஏற்கனவே sd-login.h API ஐப் பயன்படுத்தி அல்லது DBUS வழியாக libsystemd வழியாக மாற்று utmp தரவை வழங்குவதற்குத் தேவையான செயல்பாடுகளை உள்ளடக்கியது.
ஆதாரம்: opennet.ru
