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

SUSE (फ्यूचर टेक्नॉलॉजी टीम, openSUSE MicroOS आणि SLE Micro विकसित करते) मधील भविष्यातील तंत्रज्ञान विकास गटाचे नेते थोरस्टेन कुकुक, ज्यांनी यापूर्वी 10 वर्षे SUSE LINUX एंटरप्राइझ सर्व्हर प्रकल्पाचे नेतृत्व केले होते, त्यांनी /var/run/utmp फाइलपासून मुक्त होण्याचे सुचवले. Glibc मधील 2038 समस्येचे पूर्णपणे निराकरण करण्यासाठी वितरणांमध्ये. utmp, wtmp आणि लास्टलॉग वापरणारे सर्व अनुप्रयोग systemd-logind वापरून वापरकर्त्यांची यादी मिळविण्यासाठी रूपांतरित करण्याचा प्रस्ताव आहे.

19 जानेवारी, 2038 रोजी, 32-बिट time_t प्रकाराने निर्दिष्ट केलेले epochal टाइम काउंटर ओव्हरफ्लो होतील. Glibc, 64-बिट time_t प्रकार सादर करूनही, 32-बिट वापरकर्ता स्पेस ऍप्लिकेशन्ससह सुसंगतता राखण्यासाठी 64-बिट प्लॅटफॉर्मवर काही प्रकरणांमध्ये 32-बिट time_t प्रकार वापरणे सुरू ठेवते. अशीच एक केस /var/run/utmp फाइल आहे, जी सध्या सिस्टममध्ये लॉग इन केलेल्या वापरकर्त्यांचा डेटा संग्रहित करते. utmp मधील वेळ फील्ड 32-बिट time_t मूल्य वापरून निर्दिष्ट केले आहे.

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

त्याच वेळी, DoS हल्ल्यांसह समस्या सोडवताना देखील, utmp ची सामग्री केवळ माहितीपूर्ण राहते आणि वास्तविकतेच्या प्रतिबिंबाची हमी देत ​​​​नाही. उदाहरणार्थ, भिन्न अनुकरणकर्ते आणि टर्मिनल मल्टिप्लेक्सर्स त्यांची स्थिती वेगळ्या प्रकारे प्रतिबिंबित करतात - पाच GNOME टर्मिनल्स लाँच केल्याने एक वापरकर्ता utmp मध्ये परावर्तित होईल, आणि KDE मध्ये पाच konsole किंवा xterm टर्मिनल लाँच केल्याने सहा होतील. स्क्रीन आणि tmux चे वर्तन सारखेच वेगळे आहे: पहिल्या प्रकरणात, प्रत्येक सत्र स्वतंत्र वापरकर्ता म्हणून गणले जाते आणि दुसऱ्यामध्ये, सर्व सत्रांसाठी फक्त एक वापरकर्ता प्रतिबिंबित होतो.

परिणामी, सर्वात सोपा उपाय म्हणून, आधीच अस्तित्वात असलेली पर्यायी systemd-logind सेवा वापरण्यासाठी सर्व ऍप्लिकेशन्स हस्तांतरित करण्याचा प्रस्ताव आहे आणि utmp मध्ये प्रवेश करणारे कोणतेही वर्तमान प्रोग्राम नसल्यानंतर, utmp वर रेकॉर्डिंग थांबवा. wtmp बदलण्यासाठी, systemd-journald वापरणाऱ्या वापरकर्त्यांबद्दल माहिती लिहिण्यासाठी आणि वाचण्यासाठी सॉफ्टवेअर इंटरफेस तयार करण्याचा प्रस्ताव आहे. systemd 254 च्या पुढील प्रकाशनासाठी कोडबेसमध्ये sd-login.h API वापरून किंवा DBUS द्वारे libsystemd द्वारे utmp बदली डेटा प्रदान करण्यासाठी आवश्यक कार्यक्षमता आधीच समाविष्ट आहे.

स्त्रोत: opennet.ru