सिस्टीममध्ये libsystemd अवलंबित्व कमी करण्याचा विचार मांडला जातो

अलीकडे, द systemd विकासकांनी चर्चा केली ज्यामध्ये ते टेबलवर ठेवले होते libsystemd लायब्ररी अवलंबित्व कमी करण्याचा मुद्दा (सेवांची अंमलबजावणी आणि systemd शी संवाद साधण्याचे प्रभारी लायब्ररी). कारण सध्या एक निश्चित आहे प्रकल्पाद्वारे नियंत्रित नसलेल्या libsystemd मधील तृतीय पक्ष अवलंबित्व वाढविण्याबद्दल चिंता आणि हे आक्रमण पृष्ठभाग वाढवते. चर्चा स्टार्टरने नोंदवले आहे की libsystemd अनेक गंभीर लायब्ररी लोड करते, जसे की libzstd, liblz4, आणि libgcrypt, liblzma आणि glibc व्यतिरिक्त. यामुळे महत्त्वपूर्ण सुरक्षा समस्या उद्भवतात, विशेषत: या तृतीय-पक्ष लायब्ररींशी तडजोड झाल्यास.

Fedora वर, उदाहरणार्थ, 150 पेक्षा जास्त पॅकेज libsystemd वर अवलंबून असतात, ज्यामुळे गुंतागुंत आणि संबंधित जोखीम वाढते. प्रस्ताव हे संबोधित करणे समाविष्ट आहे libsystemd ला अनेक स्वतंत्र लायब्ररींमध्ये विभाजित करा, प्रत्येक विशिष्ट API साठी जबाबदार आहे. हे आवश्यक असेल तेव्हाच तृतीय-पक्ष अवलंबनांना लोड करण्यास अनुमती देईल, अशा प्रकारे लायब्ररींमधील संभाव्य असुरक्षिततेचे एक्सपोजर कमी करेल जे थेट सिस्टमड डेव्हलपर्सद्वारे नियंत्रित केले जात नाहीत.

तथापि, विकसक प्रणालीद्वारे त्यांचे म्हणणे आहे की हे वेगळे होणे समस्याप्रधान असेल libsystemd मध्ये उपस्थित असलेल्या ड्रायव्हर्सच्या इंटरकनेक्शनमुळे. त्यांचा असा विश्वास आहे की विभाजन करणे श्रम-केंद्रित असेल आणि परिणामी कार्यक्षमतेचे नुकसान होऊ शकते किंवा कोड डुप्लिकेट करण्याची आवश्यकता असू शकते, जे इच्छित सुरक्षा फायद्यांना विरोध करेल.

संपूर्ण विभक्त होण्याऐवजी, libsystemd डायनॅमिकली लोड करून अधिक डायनॅमिक दृष्टिकोनासाठी गेला आहे liblzma, libzstd आणि liblz4 लायब्ररी आवश्यकतेनुसार, dlopen() कॉल वापरून. सुरक्षा समस्या आणि कोड कार्यक्षमता आणि देखभालक्षमता या दोन्ही गरजा पूर्ण करण्यासाठी भविष्यातील प्रकाशनांमध्ये libgcrypt साठी समान बदल लागू करण्याची योजना आहे.

माझा विश्वास आहे की यापैकी बहुतेक अवलंबित्व कोर libsystemd फंक्शन्स लागू करण्यासाठी आवश्यक नाहीत, जसे की वर नमूद केल्याप्रमाणे.

या समस्येचा अर्थ libsystemd ला एकापेक्षा जास्त लायब्ररींमध्ये विभाजित करणे असू शकते जे भिन्न API ची अंमलबजावणी करतात, त्यापैकी एक, उदाहरणार्थ libsystemd-core, फक्त libc वर अवलंबून असेल, आणि इतर अधिक विशेष लायब्ररी इतर अवलंबन जोडतील. तसेच, जर काही अवलंबित्वांची फक्त ठराविक सिस्टीम सेवांसाठी गरज असेल, तर अवलंबन त्या सेवांमध्ये हलवा.

याचा अंतिम परिणाम हल्ला पृष्ठभाग कमी करणे आणि सिस्टम सुरक्षा सुधारणे हे असावे.

चर्चेदरम्यान एक मुद्दा होता ज्यावर बहुतेक विकासकांनी टीका केली, आणि ते नमूद करतात की द थर्ड पार्टी लायब्ररी लोड करण्याचा निर्णय libsystemd मध्ये dlopen() वापरणे अतिरिक्त काम निर्माण होईल निदानातील अतिरिक्त गुंतागुंत आणि लिंक दृश्यमानतेच्या अभावामुळे, ते असेही नमूद करतात की हे बाह्य लायब्ररी फंक्शन्सशी कनेक्ट होणाऱ्या libsystemd API कॉलची ओळख गुंतागुंतीचे करते, कारण ते कोडमध्ये स्पष्ट नाही. लोडिंगचा हा नवीन मार्ग, जरी तो अंतर्निहित आर्किटेक्चर बदलत नसला तरी, देखभाल करणार्या आणि वापरकर्त्यांपासून बाह्य घटक लपवतो.

लेनार्ट पॉटरिंग यांनी आपली असहमती व्यक्त केली libsystemd ला एकाधिक लायब्ररींमध्ये विभाजित करण्याच्या कल्पनेसह गुंतागुंतीमुळे हे कोड सामायिकरण आणि API आणि नेमस्पेस स्थिरता राखण्यासाठी आणेल. libsystemd विभाजित करण्यासाठी सर्व अंतर्गत ड्रायव्हर्स उघड करणे आवश्यक आहे किंवा प्रत्येक लायब्ररीमध्ये त्यांना स्वतंत्रपणे संकलित करणे आवश्यक आहे, जे कोड डुप्लिकेशनमुळे आकार वाढवू शकते किंवा सिस्टम स्थिरता आणि सुसंगतता व्यवस्थापित करणे कठीण करू शकते.

विभाजनाऐवजी, जेव्हा आवश्यक असेल तेव्हाच बाह्य लायब्ररी लोड करण्याचे धोरण इष्टतम मानले जाते, याव्यतिरिक्त, निदानातील अतिरिक्त जटिलतेचे निराकरण करण्यासाठी, लोड केलेल्या डायनॅमिक अवलंबनांबद्दल माहितीसह ELF फायलींमध्ये अतिरिक्त फील्ड जोडण्याचा प्रस्ताव आहे, ज्यामुळे डीबगरना या माहितीवर प्रक्रिया करण्याची आणि रीडेल्फ सारख्या साधनांच्या आउटपुटमध्ये ती प्रदर्शित करण्याची परवानगी मिळते. हे libsystemd द्वारे वापरल्या जाणाऱ्या डायनॅमिक अवलंबनांमध्ये अधिक पारदर्शकता आणि दृश्यमानता प्रदान करेल, त्यामुळे डायनॅमिकरित्या लोड केलेल्या बाह्य लायब्ररीशी संबंधित समस्यांचे निदान आणि डीबग करणे सोपे होईल.

लेनार्टने विकसकांना शिफारस केली अनुप्रयोगांचे जे, libsystemd शी थेट लिंक करण्याऐवजी विशिष्ट कार्यासाठी, अनुप्रयोग स्तरावर प्रोटोकॉल हँडलर लागू केला जातो.

अनुप्रयोग स्तरावर प्रोटोकॉल ड्रायव्हर्सची अंमलबजावणी करण्याचे हे धोरण अनेक फायदे देतेs:

• libsystemd वरील अवलंबित्व कमी करते आणि गरज नसताना बाह्य लायब्ररी लोड करणे टाळते.
• अनुप्रयोगासाठी आवश्यक असलेल्या विशिष्ट कार्यक्षमतेवर अधिक लवचिकता आणि नियंत्रण प्रदान करते.
• विशिष्ट फंक्शन्सच्या अंमलबजावणीवर अधिक थेट नियंत्रण ठेवून निदान आणि डीबगिंग सुलभ करते.
• सर्वसाधारणपणे, हा दृष्टिकोन मॉड्युलरिटी आणि ऍप्लिकेशन्सच्या स्वातंत्र्याला प्रोत्साहन देतो, सॉफ्टवेअर विकास आणि देखभाल मध्ये लवचिकता आणि कार्यक्षमता सुधारतो.

आपण असाल तर याबद्दल अधिक जाणून घेण्यात स्वारस्य आहे, आपण तपशील तपासू शकता पुढील लिंकवर