Glibc लाई Y2038 समस्याबाट छुटकारा दिन utmp प्रयोग गर्न बन्द गर्ने प्रस्ताव

थोरस्टेन कुकुक, SUSE (भविष्यको टेक्नोलोजी टोली, openSUSE MicroOS र SLE Micro को विकास गर्दछ) मा भविष्यको टेक्नोलोजी टोलीका नेता, जसले पहिले 10 वर्षको लागि SUSE LINUX इन्टरप्राइज सर्भर परियोजनाको नेतृत्व गरेका थिए, मा var/run/utmp फाइलबाट छुटकारा पाउन सुझाव दिए। Glibc मा Y2038 समस्यालाई पूर्ण रूपमा सम्बोधन गर्न वितरणहरू। utmp, wtmp, र lastlog प्रयोग गर्ने सबै अनुप्रयोगहरूलाई systemd-logind प्रयोग गर्ने प्रयोगकर्ताहरूको सूची प्राप्त गर्न सार्ने प्रस्ताव गरिएको छ।

जनवरी 19, 2038 मा, 32-bit time_t प्रकार द्वारा निर्दिष्ट epoch time काउन्टरहरू ओभरफ्लो हुनेछन्। Glibc मा, 64-bit time_t प्रकारको परिचयको बावजुद, 32-bit प्रयोगकर्ता-स्पेस अनुप्रयोगहरूसँग अनुकूलता कायम राख्न, 64-bit time_t प्रकार अझै पनि 32-बिट प्लेटफर्महरूमा केही अवस्थामा प्रयोग गरिन्छ। एउटा यस्तो केस /var/run/utmp फाइल हो, जसले हाल प्रणालीमा लगइन गरिएका प्रयोगकर्ताहरूको बारेमा डाटा भण्डारण गर्छ। utmp मा समय क्षेत्र 32-bit time_t मान प्रयोग गरेर सेट गरिएको छ।

केवल utmp मा 32-बिट प्रकारबाट 64-बिट प्रकारमा समयको साथमा फिल्ड परिवर्तन गर्नाले काम गर्दैन, किनकि यसले Glibc ABI परिवर्तन गर्नेछ (प्रकारले लगइन(), 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 मा पाँच कन्सोल वा xterm टर्मिनलहरू चलाउँदा छवटा परिणाम हुनेछ। त्यसैगरी, स्क्रिन र tmux को व्यवहार फरक हुन्छ, पहिलो अवस्थामा प्रत्येक सत्रलाई छुट्टै प्रयोगकर्ताको रूपमा गणना गरिन्छ, र दोस्रोमा सबै सत्रहरूको लागि मात्र एक प्रयोगकर्ता प्रतिबिम्बित हुन्छ।

नतिजाको रूपमा, सरल समाधानको रूपमा, पहिले नै अवस्थित वैकल्पिक systemd-logind सेवा प्रयोग गर्न सबै अनुप्रयोगहरू स्थानान्तरण गर्न प्रस्ताव गरिएको छ र, utmp पहुँच गर्ने कुनै वास्तविक कार्यक्रमहरू नभएपछि, utmp मा लेख्न बन्द गर्नुहोस्। wtmp लाई प्रतिस्थापन गर्न, यो systemd-journald प्रयोग गर्ने प्रयोगकर्ताहरूको बारेमा जानकारी लेख्न र पढ्नको लागि API हरू तयार गर्ने प्रस्ताव गरिएको छ। Systemd 254 को अर्को रिलीजको लागि कोडबेसले पहिले नै sd-login.h API वा DBUS मार्फत libsystemd मार्फत प्रतिस्थापन utmp डाटा प्रदान गर्न आवश्यक कार्यहरू समावेश गर्दछ।

स्रोत: opennet.ru