लिनक्स में सिक्योरिटी ब्रीच कैसे नहीं है?

Question

इस सवाल से कुछ बहुत अच्छे जवाब पढ़ने के बाद , मैं अभी भी इस बात पर फ़र्ज़ी हूं कि आप यह क्यों बहाना चाहते हैं कि आप वास्तव में मूल होने का कोई लाभ प्राप्त किए बिना जड़ हैं।

अब तक, मैं जो इकट्ठा कर सकता हूं वह यह है कि फ़ेकरूट का उपयोग किसी फ़ाइल को स्वामित्व देने के लिए किया जाता है जिसे रूट करने की आवश्यकता होती है जब यह अनज़िप / टार्ड होता है। मेरा सवाल यह है कि आप सिर्फ चांस के साथ ऐसा क्यों नहीं कर सकते?

यहां Google समूह चर्चा में बताया गया है कि आपको डेबियन कर्नेल संकलित करने के लिए फ़ेकरूट की आवश्यकता है (यदि आप इसे एक अनपेक्षित उपयोगकर्ता से करना चाहते हैं)। मेरी टिप्पणी यह ​​है कि, संकलित करने के लिए आपको रूट करने की आवश्यकता है क्योंकि शायद इसलिए कि अन्य उपयोगकर्ताओं के लिए पढ़ने की अनुमति निर्धारित नहीं थी। यदि ऐसा नहीं है, तो यह सुरक्षा उल्लंघन है कि fakeroot संकलन की अनुमति देता है (जिसका अर्थ है कि अब जीसीसी रूट के लिए एक फ़ाइल पढ़ सकता है)?

यहां यह उत्तर बताता है कि वास्तविक सिस्टम कॉल उपयोगकर्ता के वास्तविक यूआईडी / जीआईडी ​​के साथ किया जाता है , इसलिए फिर से फ़ेकरूट कहाँ मदद करता है?

फ़ाक्सकूट लिनक्स पर अवांछित विशेषाधिकार वृद्धि को कैसे रोकता है? अगर fakeroot एक फ़ाइल बनाने में टार कर सकता है जो रूट के स्वामित्व में थी, तो SUID के साथ कुछ ऐसा क्यों नहीं किया गया?

जब मैंने इकट्ठा किया है, तब से फ़ेकरूट उपयोगी है जब आप किसी भी पैकेज फ़ाइलों के स्वामी को बदलना चाहते हैं जो आपने रूट किया था। लेकिन आप ऐसा कर सकते हैं, चाउने के साथ, तो मुझे इस बात की समझ में कमी नहीं है कि इस घटक का उपयोग कैसे किया जाता है?

Comments

आपको कर्नेल संकलित करने के लिए फ़ेकरूट की आवश्यकता नहीं है। कर्नेल बिल्ड सिस्टम वह पागल नहीं है। लिंक की गई चर्चा एक डेबियन कर्नेल पैकेज बनाने के बारे में है, जिसमें वास्तविक कर्नेल बिल्ड सिर्फ एक चरण है।

@ WumpusQ। क्या मैं इसे सही करूंगा, और क्या आप मुझे बता सकते हैं कि ऐसा क्यों है?

— ng.newbie

क्योंकि फ़ेकरूट एक डेबियन चीज़ है, और लिनक्स डेबियन से अधिक है?

@ WumpusQ। किसी भी वितरण पर चलना चाहिए।

— user253751

Answer 1

अब तक, मैं जो इकट्ठा कर सकता हूं वह यह है कि फ़ेकरूट का उपयोग किसी फ़ाइल को स्वामित्व देने के लिए किया जाता है जिसे रूट करने की आवश्यकता होती है जब यह अनज़िप / टार्ड होता है। मेरा सवाल यह है कि आप सिर्फ चांस के साथ ऐसा क्यों नहीं कर सकते?

क्योंकि आप ऐसा नहीं कर सकते chown, कम से कम एक गैर-रूट उपयोगकर्ता के रूप में नहीं। (और यदि आप रूट के रूप में चल रहे हैं, तो आपको इसकी आवश्यकता नहीं है fakeroot।) इसका पूरा बिंदु है fakeroot: उन प्रोग्रामों को अनुमति देने के लिए जो रूट के रूप में सामान्य उपयोगकर्ता के रूप में चलाने की अपेक्षा करते हैं, जबकि रूट-आवश्यकता वाले ऑपरेशन सफल होते हैं।

इसका उपयोग आमतौर पर एक पैकेज का निर्माण करते समय किया जाता है, ताकि स्थापित किए जा रहे पैकेज की स्थापना प्रक्रिया त्रुटि के बिना आगे बढ़ सकती है (भले ही यह चलता है chown root:root, या install -o root, आदि)। fakerootनकली स्वामित्व को याद करता है जिसे उसने फाइलें देने का ढोंग किया था, इसलिए स्वामित्व को देखने वाले बाद के संचालन इसे वास्तविक के बजाय देखते हैं; यह tarउदाहरण के लिए फ़ाइलों को रूट के स्वामित्व में संग्रहीत करने की अनुमति देता है ।

फ़ाक्सकूट लिनक्स पर अवांछित विशेषाधिकार वृद्धि को कैसे रोकता है? अगर fakeroot एक फ़ाइल बनाने में टार कर सकता है जो रूट के स्वामित्व में थी, तो SUID के साथ कुछ ऐसा क्यों नहीं किया गया?

fakeroottarकुछ भी करने में छल नहीं करता है , यह उन परिवर्तनों को सुरक्षित रखता है जो निर्माण को उन परिवर्तनों को प्रभावित किए बिना बनाना चाहते हैं जो निर्माण की मेजबानी करने वाले सिस्टम पर प्रभाव डालते हैं। आपको fakerootरूट और suid के स्वामित्व वाली फ़ाइल वाली टारबॉल का उत्पादन करने की आवश्यकता नहीं है ; यदि आपके पास एक बाइनरी है evilbinary, तो एक tar cf evil.tar --mode=4755 --owner=root --group=root evilbinaryनियमित उपयोगकर्ता के रूप में चल रहा है , एक टारबॉल युक्त होगा evilbinary, जो रूट के स्वामित्व में है, और सुसाइड करेगा। हालाँकि, आप उस टारबॉल को निकालने और उन अनुमतियों को संरक्षित करने में सक्षम नहीं होंगे, जब तक आप ऐसा नहीं करते हैं: जब तक कि यहां कोई विशेषाधिकार नहीं है। fakerootएक विशेषाधिकार डी है-संक्रमण उपकरण: यह आपको एक नियमित उपयोगकर्ता के रूप में एक बिल्ड को चलाने की अनुमति देता है, जबकि बिल्ड के प्रभाव को संरक्षित करते हुए यदि इसे रूट के रूप में चलाया गया होता है, तो उन प्रभावों को बाद में फिर से चलाने की अनुमति मिलती है। प्रभाव "वास्तविक के लिए" हमेशा जड़ विशेषाधिकारों की आवश्यकता होती है; fakerootउन्हें प्राप्त करने का कोई तरीका प्रदान नहीं करता है।

fakerootअधिक विस्तार से उपयोग को समझने के लिए , विचार करें कि एक सामान्य वितरण बिल्ड में निम्न ऑपरेशन (कई अन्य के बीच) शामिल हैं:

• रूट द्वारा स्वामित्व वाली फ़ाइलें स्थापित करें
• ...
• उन फ़ाइलों को संग्रहीत करें, जो अभी भी रूट के स्वामित्व में हैं, ताकि जब उन्हें निकाला जाए, तो वे रूट के स्वामित्व में होंगे

यदि आप रूट नहीं हैं तो पहला भाग स्पष्ट रूप से विफल रहता है। हालांकि, जब fakerootएक सामान्य उपयोगकर्ता के रूप में चल रहा है , तो प्रक्रिया बन जाती है

• रूट के स्वामित्व वाली फ़ाइलें स्थापित करें - यह विफल रहता है, लेकिन fakerootदिखावा करता है कि यह सफल होता है, और बदले हुए स्वामित्व को याद रखता है
• ...
• उन फ़ाइलों को संग्रहित करें, जो अभी भी रूट के स्वामित्व में हैं - जब tar(या जो भी अभिलेखागार का उपयोग किया जा रहा है) सिस्टम से पूछता है कि फ़ाइल का स्वामित्व क्या है, fakerootपहले दर्ज की गई स्वामित्व से मेल खाने के उत्तर को बदल देता है

इस प्रकार आप रूट के बिना एक पैकेज बिल्ड को चला सकते हैं, जबकि यदि आप वास्तव में रूट के रूप में चल रहे थे तो वही परिणाम प्राप्त करेंगे। उपयोग करना अधिक fakerootसुरक्षित है: सिस्टम अभी भी कुछ भी नहीं कर सकता है जो आपका उपयोगकर्ता नहीं कर सकता है, इसलिए एक दुष्ट इंस्टॉलेशन प्रक्रिया आपके सिस्टम को नुकसान नहीं पहुंचा सकती है (आपकी फ़ाइलों को छूने से परे)।

डेबियन में, बिल्ड टूल्स में सुधार किया गया है ताकि इसे और अधिक की आवश्यकता न हो, और आप बिना पैकेज का निर्माणfakeroot कर सकें । यह dpkgसीधे Rules-Requires-Rootनिर्देश (देखें rootless-builds.txt) के साथ समर्थित है ।

के उद्देश्य fakerootऔर जड़ के रूप में चलने के सुरक्षा पहलुओं को समझने के लिए , यह पैकेजिंग के उद्देश्य पर विचार करने में मदद कर सकता है। जब आप सिस्टम-वाइड के उपयोग के लिए स्रोत से सॉफ़्टवेयर का एक टुकड़ा स्थापित करते हैं, तो आप निम्नानुसार आगे बढ़ते हैं:

1. सॉफ्टवेयर का निर्माण (जो विशेषाधिकारों के बिना किया जा सकता है)
2. सॉफ़्टवेयर स्थापित करें (जिसे रूट के रूप में करने की आवश्यकता है, या कम से कम उपयोगकर्ता को उपयुक्त सिस्टम स्थानों पर लिखने की अनुमति दी जाए)

जब आप सॉफ़्टवेयर का एक टुकड़ा पैकेज करते हैं, तो आप दूसरे भाग में देरी कर रहे हैं; लेकिन ऐसा सफलतापूर्वक करने के लिए, आपको अभी भी सिस्टम में सिस्टम के बजाय सॉफ्टवेयर को "इंस्टॉल" करने की आवश्यकता है। इसलिए जब आप सॉफ्टवेयर पैकेज करते हैं, तो यह प्रक्रिया बन जाती है:

1. सॉफ़्टवेयर का निर्माण करें (कोई विशेष विशेषाधिकार नहीं)
2. सॉफ़्टवेयर स्थापित करने का दिखावा (फिर से कोई विशेष विशेषाधिकार नहीं)
3. पैकेज (डिट्टो) के रूप में सॉफ्टवेयर इंस्टालेशन पर कब्जा
4. पैकेज उपलब्ध करें (डिट्टो)

अब एक उपयोगकर्ता पैकेज को स्थापित करके प्रक्रिया को पूरा करता है, जिसे रूट (या फिर, उपयुक्त स्थानों पर लिखने के लिए उपयुक्त विशेषाधिकारों वाला उपयोगकर्ता) के रूप में किया जाना चाहिए। यह वह जगह है जहां देरी विशेषाधिकार प्राप्त प्रक्रिया का एहसास होता है, और इस प्रक्रिया का एकमात्र हिस्सा है जिसे विशेष विशेषाधिकार की आवश्यकता होती है।

fakeroot हमें सॉफ़्टवेयर इंस्टॉलेशन प्रक्रियाओं को चलाने और रूट के रूप में चलने के बिना, उनके व्यवहार को पकड़ने की अनुमति देकर उपरोक्त चरणों 2 और 3 के साथ मदद करता है।

Comments

@ ng.newbie यदि आप एक वैकल्पिक स्पष्टीकरण चाहते हैं: यह मेरे लिए एक हेक्स संपादक का उपयोग करने के लिए पूरी तरह से संभव है कि रूट या किसी अन्य संभावित अनुमतियों के साथ मैन्युअल रूप से फ़ाइलों वाली टार फ़ाइल का निर्माण करें। इसकी बस कुछ जानकारी बंडल की गई, आखिरकार, इसमें कोई शक्ति नहीं है जब तक कि फ़ाइल वास्तव में सिस्टम पर मौजूद नहीं है।

— जूल

@ ng.newbie क्या आप इसे फ़ेकरूट के साथ या फ़ेकरूट के बिना खोलते हैं?

— user253751

@ ng.newbie, इसके अलावा, यदि आप दुर्भावनापूर्ण प्रयोजनों के लिए एक suid- रूट बाइनरी के साथ एक टारबॉल बनाना चाहते हैं, तो आप ऐसा कर सकते हैं कि असली रूट के रूप में किसी अन्य मशीन पर, फिर इसे लक्ष्य पर कॉपी करें। वहाँ fakeroot के लिए कोई ज़रूरत नहीं है। fakeroot टार-फाइल बनाने में मदद करने के लिए सिर्फ एक उपकरण है, यह tar --mode --ownerसंग्रह में जोड़े गए प्रत्येक फ़ाइल के लिए उपयोग करने की आवश्यकता को हटाता है (और अन्य कार्यक्रमों के साथ भी काम करता है)। संभावित मुद्दे तब आते हैं जब आप एक अविश्वसनीय टार-फाइल या आर्क को रूट के रूप में अनपैक करते हैं, न कि इसे बनाते समय।

— इलकाचु जू

Answer 2

नहीं। नकली रूट आपको अनुमति हेरफेर और रिपोर्टिंग उपकरण चलाने की अनुमति देता है, यह लगातार रिपोर्ट करेगा। हालाँकि यह वास्तव में इन अनुमतियों को प्रदान नहीं करेगा। ऐसा लगेगा जैसे आप उन्हें (नकली) हैं। यह पर्यावरण के बाहर कुछ भी नहीं बदलेगा।

यह उपयोगी है, यदि आप एक निर्देशिका संरचना बनाना चाहते हैं, जिसमें स्वामित्व और अनुमतियां शामिल हैं, जो आपके उपयोगकर्ता द्वारा सेट नहीं की जा सकती हैं, तो आप तब टार, ज़िप या अन्य पैकेज करेंगे।

यह वास्तव में अनुमतियों को नहीं बढ़ाता है, यह नकली है। यह आपको कुछ भी करने नहीं देता (हटाएं, लिखें, पढ़ें) जो आप अन्यथा नहीं कर सकते। आप इसके बिना पैकेज (सिद्धांत में) का उत्पादन कर सकते थे। आप इसके lsबिना एक नकली रिपोर्ट ( ) प्राप्त कर सकते हैं ।

यह एक सुरक्षा दोष नहीं है, क्योंकि यह पहुंच, या ऐसी किसी भी चीज़ की अनुमति नहीं देता है जिसे आप इसके बिना नहीं कर सकते। यह विशेषाधिकार के बिना चलता है। यह सब खुराक है इंटरसेप्ट कॉल टू chown, chmodआदि। यह उन्हें एक ऑपरेशन नहीं बनाता है, सिवाय इसके कि यह रिकॉर्ड करता है कि क्या हुआ होगा। यह कॉल statआदि को भी इंटरसेप्ट करता है ताकि यह अपने स्वयं के आंतरिक डेटाबेस से अनुमति और स्वामित्व की रिपोर्ट करे, जैसे कि अन्य कमांड किया गया था। यह उपयोगी है, क्योंकि यदि आप फिर निर्देशिका को ज़िप करते हैं, तो इसके पास नकली अनुमतियाँ होंगी। यदि आप तब रूट के रूप में अनज़िप करते हैं, तो अनुमतियाँ वास्तविक हो जाएंगी।

कोई भी फाइल जो पहले पढ़ने योग्य / लिखने योग्य नहीं है, पढ़ने योग्य / लिखने योग्य नहीं रहेगी। बनाई गई किसी भी विशेष फाइल (जैसे डिवाइस) में कोई विशेष शक्तियां नहीं होंगी। कोई भी सेट-यूआईडी (दूसरे उपयोगकर्ता के लिए), फाइलें सेट-यूआईडी नहीं होंगी। किसी अन्य विशेषाधिकार वृद्धि से काम नहीं चलेगा।

यह एक प्रकार की वर्चुअल मशीन है: एक वर्चुअल मशीन, सामान्य रूप से, किसी भी वातावरण / OS का अनुकरण कर सकती है, लेकिन मेजबान के लिए ऐसा कुछ भी नहीं कर सकती है, जो कोई अन्य एप्लिकेशन नहीं कर सकता। वर्चुअल मशीन के भीतर, आप कुछ भी कर सकते हैं। आप एक या अलग होने के लिए सुरक्षा प्रणाली को फिर से मजबूत कर सकते हैं, हालांकि यह सभी मेजबान पर मौजूद होगा, क्योंकि वर्चुअल वातावरण चलाने वाली प्रक्रिया के उपयोगकर्ता / समूह के स्वामित्व वाले संसाधन।

Comments

@ ctrl-alt-सजावट जैसा कि मैंने उपरोक्त टिप्पणी में पूछा है, * निक्स में मालिक को किसी अन्य अनपेक्षित उपयोगकर्ता से रूट करना संभव नहीं है, सही है? तो इसके लिए एक अच्छा कारण होना चाहिए कि अगर कोई कार्यक्रम इसकी अनुमति देता है, तो यह सुरक्षा दोष कैसे है?

— ng.newbie

@ ctrl-alt-सजावट fakeroot मुझे पढ़ने / लिखने / हटाने की अनुमति नहीं देता है, लेकिन अगर मैंने syscalls के लिए एक आवरण लिखा है तो क्या यह इस कारण से खड़ा है कि मैं उन कार्यों को भी कर सकता हूं।

— ng.newbie

@ ctrl-alt-सजावट तो fakeroot के अस्तित्व का एकमात्र कारण रूट के बिना रूट करने के लिए फ़ाइल की अनुमतियाँ सेट करना है। यदि वह सुरक्षा दोष नहीं है, तो लिनक्स उसे पहले स्थान पर क्यों अस्वीकार करेगा?

— ng.newbie

कोई यह करने की अनुमति देता नकली किसी भी उपयोगकर्ता के लिए उपयोगकर्ता की स्थापना, और नकली कुछ अन्य बातों के। इसे आज़माएं: फ़ेकरूट चलाएं और बाहर से फ़ाइलों को देखें, फ़ाइलों को एक्सेस करने का प्रयास करें, जो आपको नहीं करना चाहिए।

— सीटीएल-अल्ट-डेलोर

Answer 3

यहां पहले से ही दो अच्छे, और बहुत विस्तृत उत्तर हैं, लेकिन मैं सिर्फ यह बताता हूं कि मूल fakeroot मैन पेज ¹ का परिचयात्मक पैराग्राफ वास्तव में इसे बहुत स्पष्ट और संक्षिप्त रूप से समझाता है:

fakeroot एक ऐसे वातावरण में एक कमांड चलाता है जिसमें फ़ाइल हेरफेर के लिए रूट विशेषाधिकार है। यह उपयोगकर्ताओं को रूट अनुमतियाँ / स्वामित्व वाली फ़ाइलों के साथ अभिलेखागार (टार, अर, .deb आदि) बनाने की अनुमति देने के लिए उपयोगी है। फ़ेकरूट के बिना किसी को अभिलेखों की घटक फ़ाइलों को सही अनुमतियों और स्वामित्व के साथ बनाने के लिए रूट विशेषाधिकार की आवश्यकता होगी, और फिर उन्हें पैक करना होगा, या किसी को अभिलेखागार का उपयोग किए बिना सीधे अभिलेखागार का निर्माण करना होगा।

फ़ेकरूट एक गैर-रूट उपयोगकर्ता को रूट-स्वामित्व वाली फ़ाइलों को बनाने की अनुमति देता है, जो लिनक्स में बाइनरी सॉफ़्टवेयर पैकेजों को बनाने और वितरित करने का एक महत्वपूर्ण हिस्सा है। बिना fakeroot, पैकेज अभिलेखागार को वास्तविक रूट के रूप में चलाते समय उत्पन्न करना होगा, ताकि उनके पास सही फ़ाइल स्वामित्व और अनुमतियां हों। यही कारण है कि होगा सुरक्षा जोखिम हो। यदि रूट निजी के साथ किया जाता है तो बिल्डिंग और पैकेजिंग संभावित अविशिष्ट सॉफ्टवेयर एक बहुत बड़ा जोखिम है। के लिए धन्यवाद fakeroot, अनपेक्षित फ़ाइलों के साथ एक अप्रकाशित उपयोगकर्ता अभी भी रूट स्वामित्व वाली फ़ाइलों के साथ अभिलेखागार उत्पन्न कर सकता है। ²

लेकिन यह एक सुरक्षा जोखिम नहीं है, क्योंकि संग्रह में कुछ भी वास्तव में रूट के स्वामित्व में नहीं है जब तक कि फाइलें एक्सट्रैक्टेड नहीं होती हैं । और फिर भी, फ़ाइलों को केवल उनकी रूट अनुमतियों के साथ ही निकाला जाएगा यदि यह किसी विशेषाधिकार प्राप्त उपयोगकर्ता द्वारा किया जाता है। वह चरण - जहां fakeroot"रूट" फ़ाइलों वाले एक- संग्रहीत संग्रह को एक विशेषाधिकार प्राप्त उपयोगकर्ता द्वारा निकाला जाता है - जहां "नकली" रूट अंत में वास्तविक है। उस बिंदु तक, कोई वास्तविक मूल विशेषाधिकार कभी भी प्राप्त या बायपास नहीं किए जाते हैं।

टिप्पणियाँ

1. फ़ेकरूट ने कुछ प्रतियोगियों / नकल करने वालों को उकसाया है fakeroot, जो स्थापित होने पर, सहित, fakeroot-ngऔर pseudo। लेकिन IMHO न तो "इमिटेटर का" मैन पेज लगभग इस सवाल पर बिंदु के अधिकार के बारे में स्पष्ट है। मूल, एक और केवल fakerootओजी के साथ रहना

2. अन्य डिस्ट्रोस / पैकेजिंग-सिस्टम अपने पैकेज अभिलेखागार में रूट स्वामित्व का उपयोग न करके इसे दूर करते हैं। उदाहरण के लिए, फ़ेडोरा पर, सॉफ़्टवेयर को बिना आवश्यक उपयोगकर्ता द्वारा संकलित, स्थापित और पैक किया जा सकता है fakeroot। यह सब कुछ उपयोगकर्ता के भीतर किया है $HOME/rpmbuild/जगह है, और की तरह सामान्य रूप से-विशेषाधिकार चरणों make install(जैसे तंत्र के माध्यम से प्राप्त पुनर्निर्देशित --prefixऔर DESTDIRएक करने के लिए) $HOME/rpmbuild/BUILDROOT/पदानुक्रम कि (वास्तव में उपयोग किए बिना "fakechroot" अंतरिक्ष का एक तरह माना जा सकता है fakechroot)।

   लेकिन फिर भी make install, सब कुछ के रूप में निष्पादित और स्वामित्व वाले उपयोगकर्ता द्वारा किया जाता है। निकाले फ़ाइल का स्वामित्व और अनुमतियाँ पर निर्धारित किया जाएगा root,rootऔर 0644(या 0755डिफ़ॉल्ट रूप से निष्पादन योग्य के लिए) जब तक पैकेज परिभाषा (में अधिरोहित .specजो मामले में वे अंतिम पैकेज में मेटाडाटा के रूप में जमा कर रहे हैं) फ़ाइल। क्योंकि आरपीएम पैकेज (विशेषाधिकार प्राप्त) की स्थापना प्रक्रिया तक कोई भी अनुमति या स्वामित्व वास्तव में लागू नहीं होता है, fakerootपैकेजिंग के दौरान न तो रूट की आवश्यकता होती है और न ही इसकी आवश्यकता होती है। लेकिन fakerootवास्तव में उसी परिणाम के लिए एक अलग रास्ता है।

Comments

अपने पहले नोट के बारे में, fakeroot-ng सुपरसेड करने का दावा करता है fakeroot, लेकिन व्यवहार में इसे प्रतिस्थापित नहीं किया है, और AFAIK fakerootअभी भी डिफ़ॉल्ट रूप से (आवश्यक होने पर) डेबियन में उपयोग किया जाने वाला उपकरण है।

— स्टीफन किट

@StephenKitt अहा! धन्यवाद। मुझे इसके बारे में ही ख्याल आ रहा था। शुरू में मैं उलझन में था क्योंकि मैं fakerootमैनपेज की खोज में गया था , और Google ने मुझे fakeroot-ng'एस' के रूप में संदेश दिया है fakeroot(1), और मुझे लगता है कि मैंने ओवरस्प्रेम्ड किया। लेकिन अब मैं देख रहा हूं कि 2014 के बाद से fakeroot-ng को अपडेट नहीं किया गया है , जबकि fakeroot अभी भी सक्रिय है । जाहिरा तौर पर छद्म भी है जिसने कुछ साल पहले इसे बनाया था, लेकिन अब ठप हो गया है। मैं उसी के अनुसार अपना उत्तर दूंगा।

— FeRD

हाँ मैं पहले भी पर भ्रमित किया गया था, के बाद से डेबियन की साइट पर मैनपेज पर ले जाया जाता डिफ़ॉल्ट रूप से की संस्करण। एक मनोरंजक मोड़ ;-) के लिए अंतिम पैराग्राफ देखें । fakerootfakeroot-ngfakeroot-ng

— स्टीफन किट