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

एसयूएसई (फ्यूचर टेक्नोलॉजी टीम, ओपनएसयूएसई माइक्रोओएस और एसएलई माइक्रो विकसित करता है) में भविष्य के प्रौद्योगिकी विकास समूह के नेता थॉर्स्टन कुकुक, जिन्होंने पहले 10 वर्षों तक एसयूएसई लिनक्स एंटरप्राइज सर्वर प्रोजेक्ट का नेतृत्व किया था, ने /var/run/utmp फ़ाइल से छुटकारा पाने का सुझाव दिया Glibc में 2038 समस्या को पूरी तरह से संबोधित करने के लिए वितरण में। यूटीएमपी, डब्ल्यूटीएमपी और लास्टलॉग का उपयोग करने वाले सभी एप्लिकेशन को सिस्टमडी-लॉगइंड का उपयोग करके उपयोगकर्ताओं की सूची प्राप्त करने के लिए परिवर्तित करने का प्रस्ताव है।

19 जनवरी, 2038 को, 32-बिट टाइम_टी प्रकार द्वारा निर्दिष्ट युगांतरकारी समय काउंटर ओवरफ्लो हो जाएंगे। Glibc, 64-बिट टाइम_टी प्रकार पेश करने के बावजूद, 32-बिट उपयोगकर्ता स्पेस अनुप्रयोगों के साथ संगतता बनाए रखने के लिए 64-बिट प्लेटफ़ॉर्म पर कुछ मामलों में 32-बिट टाइम_टी प्रकार का उपयोग करना जारी रखता है। ऐसा ही एक मामला /var/run/utmp फ़ाइल है, जो वर्तमान में सिस्टम में लॉग इन उपयोगकर्ताओं के बारे में डेटा संग्रहीत करता है। Utmp में समय फ़ील्ड 32-बिट time_t मान का उपयोग करके निर्दिष्ट किया गया है।

केवल utmp में समय फ़ील्ड को 32-बिट से 64-बिट प्रकार में बदलने से काम नहीं चलेगा, क्योंकि इससे Glibc ABI में बदलाव आएगा (लॉगिन(), getutid() और utmpname जैसे फ़ंक्शंस में प्रकार बदल जाएगा) ()) और यूटीएमपी का उपयोग करने वाले अनुप्रयोगों के साथ संगतता को तोड़ना, जिसमें डब्ल्यू, हू, अपटाइम, लॉगिन, सु, सुडो, यूजरएड, सिस्टमड, सिसविनिट, टीसीएसएच, एक्सटर्म डिस्प्ले मैनेजर, ईमैक, ओपनश, क्यूएमयू, सांबा, आरएसआईलॉग इत्यादि शामिल हैं। संभावित नुकसान और जटिलता की प्रचुरता के कारण, utmp में time_t प्रकार को बदलने का विचार Glibc डेवलपर्स द्वारा अस्वीकार कर दिया गया था। इसी कारण से, अतिरिक्त 64-बिट समय फ़ील्ड जोड़ने के लिए utmp संरचना में उपलब्ध खाली स्थान का उपयोग करने का विकल्प छोड़ दिया गया था।

इसके अलावा, utmp में टाइप बिट डेप्थ बदलने से अन्य मौजूदा समस्याएं हल नहीं होती हैं, जिनसे मैं भी छुटकारा पाना चाहूंगा। उदाहरण के लिए, utmp को लिखने के लिए विशेष अधिकारों की आवश्यकता होती है, जिसके लिए प्रक्रियाओं को अतिरिक्त विशेषाधिकार दिए जाने की आवश्यकता होती है। एक और समस्या यह है कि utmp आर्किटेक्चर स्थानीय उपयोगकर्ताओं को DoS हमलों को अंजाम देने की अनुमति देता है, जिससे फ़ाइल लॉक में हेरफेर के माध्यम से utmp सेवा में व्यवधान होता है, जिससे यह सुनिश्चित करना असंभव हो जाता है कि utmp की सामग्री सिस्टम में वास्तविक स्थिति को दर्शाती है। utmp तक पहुंच को संभालने के लिए एक अतिरिक्त पृष्ठभूमि प्रक्रिया का उपयोग करने का प्रस्ताव किया गया था, लेकिन ऐसे कार्यों के लिए पहले से ही एक सिस्टमड-लॉगइंड प्रक्रिया है और एक और विशेष प्रक्रिया लॉन्च करना उचित नहीं है (एप्लिकेशन को एक साथ दो हैंडलर को डेटा स्थानांतरित करना होगा)।

साथ ही, DoS हमलों के साथ समस्या को हल करते समय भी, utmp की सामग्री केवल सूचनात्मक रहती है और वास्तविकता के प्रतिबिंब की गारंटी नहीं देती है। उदाहरण के लिए, अलग-अलग एमुलेटर और टर्मिनल मल्टीप्लेक्सर्स अपनी स्थिति को अलग-अलग तरीके से दर्शाते हैं - पांच GNOME टर्मिनल लॉन्च करने से एक उपयोगकर्ता utmp में प्रतिबिंबित होगा, और KDE में पांच कंसोल या xterm टर्मिनल लॉन्च करने से छह उपयोगकर्ता दिखाई देंगे। स्क्रीन और tmux का व्यवहार समान रूप से भिन्न है: पहले मामले में, प्रत्येक सत्र को एक अलग उपयोगकर्ता के रूप में गिना जाता है, और दूसरे में, सभी सत्रों के लिए केवल एक उपयोगकर्ता प्रतिबिंबित होता है।

परिणामस्वरूप, सबसे सरल समाधान के रूप में, पहले से मौजूद वैकल्पिक सिस्टमड-लॉगइंड सेवा का उपयोग करने के लिए सभी एप्लिकेशन को स्थानांतरित करने का प्रस्ताव है और, जब कोई वर्तमान प्रोग्राम यूटीपी तक नहीं पहुंच रहा है, तो यूटीएमपी पर रिकॉर्डिंग बंद कर दें। डब्ल्यूटीएमपी को बदलने के लिए, सिस्टमड-जर्नल का उपयोग करने वाले उपयोगकर्ताओं के बारे में जानकारी लिखने और पढ़ने के लिए सॉफ्टवेयर इंटरफेस तैयार करने का प्रस्ताव है। सिस्टमडी 254 के अगले रिलीज के लिए कोडबेस में पहले से ही sd-login.h एपीआई या डीबीयूएस के माध्यम से libsystemd के माध्यम से यूटीएमपी प्रतिस्थापन डेटा प्रदान करने के लिए आवश्यक कार्यक्षमता शामिल है।

स्रोत: opennet.ru