Glibc ला 2038 च्या समस्येपासून मुक्त करण्यासाठी, utmp वापरणे थांबवण्याचा प्रस्ताव आहे

SUSE (openSUSE MicroOS आणि SLE Micro चे डेव्हलपर) येथील फ्युचर टेक्नॉलॉजी टीमचे नेते थॉर्स्टन कुकुक, ज्यांनी यापूर्वी SUSE Linux Enterprise Server प्रकल्पाचे १० वर्षे नेतृत्व केले होते, त्यांनी Glibc वर्ष २०३८ च्या समस्येचे पूर्णपणे निराकरण करण्यासाठी /var/run/utmp फाइल वितरणातून काढून टाकण्याचा प्रस्ताव मांडला. utmp, wtmp आणि lastlog वापरणारे सर्व अनुप्रयोग systemd-logind वापरून वापरकर्ता सूची पुनर्प्राप्त करण्यासाठी स्थलांतरित करण्याचा प्रस्ताव आहे.

१९ जानेवारी २०३८ रोजी, ३२-बिट time_t प्रकाराद्वारे निर्दिष्ट केलेले युगकालीन वेळ काउंटर ओव्हरफ्लो होतील. ६४-बिट time_t प्रकार सुरू असूनही, Glibc लायब्ररी काही प्रकरणांमध्ये ६४-बिट प्लॅटफॉर्मवर ३२-बिट time_t प्रकार वापरणे सुरू ठेवते जेणेकरून ३२-बिट वापरकर्ता-स्पेस अनुप्रयोगांसह सुसंगतता राखता येईल. असाच एक प्रकार /var/run/utmp फाइल आहे, जी सध्या सिस्टमवर लॉग इन केलेल्या वापरकर्त्यांबद्दल डेटा संग्रहित करते. utmp मधील वेळ फील्ड ३२-बिट time_t मूल्य वापरून निर्दिष्ट केले आहे.

utmp मधील ३२-बिट टाइम फील्डला फक्त ६४-बिट प्रकाराने बदलणे शक्य नाही, कारण यामुळे Glibc ABI बदलेल (login(), getutid(), आणि utmpname() सारख्या फंक्शन्समधील प्रकार बदलेल) आणि utmp वापरणाऱ्या अॅप्लिकेशन्ससह सुसंगतता खंडित होईल, ज्यामध्ये w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm डिस्प्ले मॅनेजर्स, emacs, openssh, qemu, samba, rsyslog आणि इतर समाविष्ट आहेत. संभाव्य अडचणींच्या विपुलतेमुळे आणि त्यात समाविष्ट असलेल्या जटिलतेमुळे, utmp मधील time_t प्रकार बदलण्याची कल्पना Glibc डेव्हलपर्सनी नाकारली. त्याच कारणास्तव, अतिरिक्त ६४-बिट टाइम फील्ड जोडण्यासाठी utmp स्ट्रक्चरमध्ये उपलब्ध मोकळी जागा वापरण्याचा पर्याय नाकारण्यात आला.

शिवाय, utmp फाइल प्रकाराची बिट डेप्थ बदलल्याने इतर विद्यमान समस्या सोडवल्या जात नाहीत ज्या सोडवणे देखील इष्ट आहे. उदाहरणार्थ, utmp वर लिहिण्यासाठी विशेष परवानग्या आवश्यक असतात, ज्यासाठी प्रक्रियांना अतिरिक्त विशेषाधिकार देणे आवश्यक असते. दुसरी समस्या अशी आहे की utmp आर्किटेक्चर स्थानिक वापरकर्त्यांना DoS हल्ले करण्याची परवानगी देते जे फाइल लॉकमध्ये फेरफार करून utmp सेवेमध्ये व्यत्यय आणतात, ज्यामुळे 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