34

मैं सोच रहा था कि रूट उपयोगकर्ता की तुलना में अनुमतियों के साथ उपयोगकर्ता के लिए फायदेमंद हो सकता है।

आप देखते हैं, मैं सभी गतिविधियों और लगभग सभी मौजूदा रूट उपयोगकर्ता विशेषाधिकारों को ठीक वैसे ही रखना चाहूंगा जैसे वे अब हैं।

हालाँकि, मैं विशेष आधार पर केस के आधार पर विशेषाधिकारों को अस्वीकार करने की क्षमता को पसंद करूंगा।

इसके फायदों में से एक मुझे अपडेट के दौरान कुछ अनचाहे फाइलों को इंस्टॉल होने से रोकने की अनुमति देगा। यह केवल एक संभावित लाभ का एक उदाहरण है।

क्योंकि apt-get अपडेट रूट द्वारा या sudo विशेषाधिकार के साथ चलाए जाते हैं, apt-get में अपडेट के दौरान कुछ अवांछित फ़ाइलों को बदलने की क्षमता होती है।

यदि मैं इन विशेष फ़ाइलों के लिए इन विशेषाधिकारों का खंडन कर सकता हूं, तो मैं उन्हें एक simlink के रूप में सेट कर सकता हूं /dev/nullया संभवतः एक रिक्त प्लेसहोल्डर फ़ाइल हो सकती है जो अनुमतियाँ हो सकती हैं जो अद्यतन के दौरान फ़ाइल को बदलने से इनकार कर सकती हैं।

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

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

मैंने अभी इस बारे में सोचा है और अभी तक इस विचार पर कोई समय नहीं लगाया है और मुझे पूरा विश्वास है कि यह पता लगाया जा सकता है। हालांकि, मैं यह जानने के लिए उत्सुक हूं कि क्या यह पहले से ही किया गया है या यदि यह संभवतः एक नया विचार या अवधारणा नहीं है।

मूल रूप से, ऐसा लगता है कि एक सुपर सुपर-उपयोगकर्ता के लिए कुछ रास्ता होना चाहिए जो केवल एक डिग्री से सिस्टम से परे अनुमति होगी।

नोट: हालांकि मुझे लगता है कि स्वीकृत उत्तर सबसे अधिक मापदंड को फिट करता है, मुझे वास्तव में @CR द्वारा उत्तर पसंद है। भी।

मैं पेड़ पर एक वास्तविक उपयोगकर्ता बनाना चाहता हूं (मुझे) लेकिन मुझे लगता है कि मुझे केवल एक दिन बैठना होगा जब मेरे पास यह पता लगाने का समय होगा।

इसके अतिरिक्त, मैं यहाँ उबंटू चुनने की कोशिश नहीं कर रहा हूँ; अगर मैं इसके बारे में नकारात्मक महसूस करता हूं तो मैं इसे अपने मुख्य डिस्ट्रो के रूप में उपयोग नहीं करूंगा।

— mchid
स्रोत

4

आप किस तरह की फाइलों के बारे में बात कर रहे हैं और क्यों? " कुछ अवांछित फ़ाइलों को स्थापित होने से रोकें _" सुझाव देता है कि फाइलें (सामान्य रूप से) मौजूद नहीं हैं, और आप उन्हें ऐसा करने से रोकना चाहते हैं; लेकिन "_hat अद्यतन के दौरान फ़ाइल को प्रतिस्थापित करने से इनकार करेगा। " पहले से मौजूद फ़ाइलों के साथ सुझाव देता है (साथ, संभवतः वांछनीय सामग्री) और आप नए संस्करण नहीं चाहते हैं।

— ट्रिपएपाउंड

6

ध्यान रखें कि aptफ़ाइलों को लिखने (ओवर) से रोकने वाली कोई भी विधि , त्रुटि को जन्म दे सकती है, अद्यतन प्रक्रिया को निरस्त कर सकती है। aptतब तक कोई भी अपडेट या इंस्टॉलेशन करने से मना कर देगा जब तक कि "समस्या" हल न हो जाए।

— डब

6

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

— केविन

8

@mchid: जड़ है पूरा नियंत्रण। इसका पूरा मतलब यही है। इसे पूर्ण नियंत्रण नहीं बनाने के लिए, आपको बहुत सी चीजों से इनकार करना होगा कि यह अब रूट की तरह नहीं दिखता है (जैसे कि कर्नेल मॉड्यूल स्थापित नहीं करना, कोई बढ़ते मनमानी उपकरण, और इतने पर नहीं)। यदि आप चीजों को जड़ के रूप में नहीं चलाना चाहते हैं, तो उन्हें जड़ के रूप में न चलाएं। इसके बजाय, क्षमताओं को छोड़ दें (सभी रूट-समतुल्य लोगों को छोड़कर , उन लोगों से परेशान न हों) या पॉलकिट की तरह एक डेमॉन चलाएं जो गैर-रूट प्रक्रियाओं की ओर से रूट संचालन करता है।

— केविन

4

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

— केविन

83

"उपयोगकर्ता" जो आप चाहते हैं, उसे एलएसएम कहा जाता है: लिनक्स सुरक्षा मॉड्यूल। सबसे अच्छी तरह से ज्ञात SELinux और AppArmor हैं।

इसके द्वारा आप कुछ बायनेरिज़ (और उनकी बाल प्रक्रियाओं) को कुछ सामान करने से रोक सकते हैं (भले ही उनका यूआईडी हो root)। लेकिन आप इन कार्यों को gettyऔर इसकी बाल प्रक्रियाओं को करने की अनुमति दे सकते हैं ताकि आप इसे मैन्युअल रूप से कर सकें।

— हाक लागिंग
स्रोत

2

लेकिन अगर उनका UID रूट है तो क्या वे selinux परमिशन को नहीं बदल सकते हैं जो उन्हें पहले स्थान पर पहुंचने से रोकते हैं?

— जिज्ञासु_काट

11

@curious_cat: हां, निश्चित रूप से आपको "सीमित रूट" प्रक्रिया को अस्वीकार करने की आवश्यकता है ताकि वह अपनी स्वयं की अनुमति को बदल / बढ़ा सके! SELinux को लिखने वाले लोगों ने पहले से ही ऐसा सोचा था ...

— पीटर कॉर्ड्स

8

@curious_cat आप LSM को कॉन्फ़िगर कर सकते हैं ताकि रन समय पर उनके कॉन्फ़िगरेशन को बदलना पूरी तरह से असंभव हो। आपको रिबूट करना होगा और उसके बाद कर्नेल पैरामीटर देना होगा।

— हौके लैजिंग

5

@ जोशुआ अगर आपके -प्ट की कॉपी रोहमर का उपयोग कर रही है तो आपको चिंता करने की बड़ी समस्या है।

— ड्रेकोनिस

3

@corsiKa सबसे पहले, आप उन लोगों को प्रतिबंधित करना चाहते हैं जो मशीन को बूट कर सकते हैं जो वास्तव में मशीन पर हैं, क्योंकि सिस्टम बूट होने के दौरान कमजोर होते हैं। नेट पर एक रिबूट को ट्रिगर करना ठीक है, लेकिन नियंत्रण की अनुमति देना क्योंकि यह बूट नहीं है। दूसरा, कंप्यूटर सुरक्षा का एक नियम यह है कि एक हमलावर के पास भौतिक पहुंच होने के बाद आप कुछ नहीं कर सकते, क्योंकि तब वे एलएन 2 में सब कुछ डुबो सकते हैं या हार्डवेयर / आदि को फिर से खोल सकते हैं। तो, हाँ, जो कोई मशीन के बूटिंग को बदल सकता है, उसे आमतौर पर मशीन को "जीता" माना जाता है।

— HTNW

51

आप rootउपयोगकर्ता की अवधारणा को गलत समझ रहे हैं ।

सादे अंग्रेजी में, root"पेड़ के ऊपर" है।

क्या होगा यदि आप एक "सुपर सुपर उपयोगकर्ता" के लिए एक दिन तय करते हैं, और फिर अगले महीने, एक "सुपर सुपर उपयोगकर्ता" (!)। आप कितनी दूर "पेड़" पर जाना चाहेंगे? आप उस कार्य को करने के लिए सभी अनुमतियों और पदानुक्रम को कैसे बदलेंगे? हमेशा शीर्ष पर कौन है? किसी को सबसे ऊपर होना है, और यह है root। कहानी का अंत।

यहां दिए गए समाधान - AppArmor और SELinux सहित - वास्तव में इसे नहीं बदलते हैं। वे बस अनुमति rootऔर प्रक्रियाओं पर बारीक अनाज नियंत्रण की अनुमति देते हैं।

यह मुझे लगता है जैसे आपकी अपडेट प्रक्रिया वांछित परिणाम के लिए उपयुक्त नहीं है। लेकिन इसमें rootयूजर की गलती नहीं है । चीजों को ओवरकॉम्प्लिकेट करने के बजाय, rootउच्चतम स्तर के अनुमति उपयोगकर्ता के रूप में सोचें , और फिर बाकी सब कुछ, आपको नीचे की ओर काम करना होगा।

मुझे पता है कि कुछ लोग इसे नीचे चिह्नित करेंगे, लेकिन उपयोगकर्ता पदानुक्रम में कोई उच्च स्तर नहीं है, और सभी अन्य समाधान बस थोड़ा अलग नियंत्रण देते हैं कि rootअनुमतियाँ कैसे काम करती हैं। लेकिन वे उच्च अनुमतियों के साथ एक नया उपयोगकर्ता नहीं बनाते हैं ।

आपके पास "अधिक अनुमतियाँ" वाला उपयोगकर्ता नहीं हो सकता है rootक्योंकि rootउच्चतम स्तर की अनुमतियों का प्रतिनिधित्व संभव है। "रूट से अधिक नियंत्रण" जैसे वाक्यांश का उपयोग करना एक विरोधाभास है - rootपूर्ण नियंत्रण और सभी संभव अनुमतियाँ हैं, इसलिए ऐसा कुछ भी नहीं है जो इसके ऊपर किया जा सकता है।

— एंडी
स्रोत

मैं कहानी के अंत में जड़ नहीं, सबसे ऊपर होगा। क्योंकि उपयोगकर्ता पदानुक्रम में कोई उच्च स्तर नहीं है, इसलिए सटीक कारण है कि मैं एक उच्च उपयोगकर्ता बनाना चाहूंगा।

— mchid

हालाँकि, मैं जैसा चाहता हूं, वह है: रूट अनुमतियों और प्रक्रियाओं पर नियंत्रण ताकि मैं रूट को अनुमति देने से इनकार कर सकूं। अगर मैं किसी भी तरह से SELinux या AppArmor के साथ एक नया उपयोगकर्ता बनाने के बिना रूट करने की अनुमति से इनकार कर सकता हूं, तो मुझे लगता है कि मुझे नए उपयोगकर्ता की आवश्यकता नहीं है। मैं पूर्ण नियंत्रण चाहता हूं, जड़ से अधिक नियंत्रण।

— mchid

16

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

— एंडी

@ mchid तो आप वास्तव में क्या करना चाहते हैं, वर्तमान रूट उपयोगकर्ता को mchid का नाम बदलें, रूट नामक एक नया उपयोगकर्ता बनाएं और apt-get et al अपने नए, गैर-रूट उपयोगकर्ता का उपयोग करें?

— ओडालरिक

कुछ प्रणालियों में, rootहार्डवेयर को सीधे एक्सेस करने की अनुमति नहीं है। यदि आप कर्नेल मॉड्यूल के लोडिंग को अक्षम करते हैं, तो आप रूट को हार्डवेयर पर कुल नियंत्रण से बाहर रख सकते हैं ( /dev/memऔर उस तरह सामान)। फाइलसिस्टम अनुमतियों के लिए वास्तव में प्रासंगिक नहीं है, क्योंकि आप अपने एसटीए या एनवीएमई नियंत्रक से सीधे बात करने वाले एप-गेट का उपयोग नहीं करेंगे ... लेकिन तकनीकी रूप से, root"राज्य की तुलना में अधिक अनुमतियाँ " हैं, और इसे कर्नेल मोड कहा जाता है। : पी

— पीटर कॉर्ड्स

26

यदि आप फ़ाइलों या निर्देशिकाओं को बदलने / हटाने से रोकना चाहते हैं, तो बस उन पर अपरिवर्तनीय ध्वज सेट करें।

chattr +i <file>

जब तक झंडे को नहीं हटाया जाएगा, तब तक रूट भी उन्हें कुछ नहीं कर पाएगा। रूट एक्सेस को रोकने के लिए कंटेनर / नेमस्पेस सिस्टम का उपयोग करना भी संभव है लेकिन जो आपको चाहिए उसके लिए ओवरकिल की तरह लगता है।

— सीआर।
स्रोत

11

लेकिन रूट झंडे को हटा सकता है।

— 21

10

उपयुक्त, लगभग सब कुछ की तरह, उस झंडे को हटाने के लिए चैटट्रैड का उपयोग नहीं करेगा।

— सी.आर.

13

@sebasth: सही, लेकिन Apt, dpkg और प्रति-पैकेज इंस्टॉलेशन स्क्रिप्ट्स (सामान्य रूप से) फ़ाइल विशेषताओं में परिवर्तन नहीं करेगी। इसके बजाय वे बस असफल हो जाएंगे और शिकायत करेंगे जब वे अपरिवर्तनीय ध्वज के साथ फ़ाइलों को बदलने की कोशिश करेंगे।

— डेविड फ़ॉस्टर

4

@TripeHound तो ओपी apt-getफ़ाइल को प्रतिस्थापित करने में सफल होना चाहता है, फिर भी उस फ़ाइल को बरकरार रखना है? यह कुछ विरोधाभासी है जो मैं कहता हूं।

— दिमित्री ग्रिगोरीव

3

@DmitryGrigoryev ऐसा लगता है कि वे यह सोचना चाहते apt-getहैं कि यह सफल हो गया लेकिन एक या एक से अधिक फ़ाइलों को अपरिवर्तित छोड़ दिया। वे यह नहीं कहते कि कौन सी फाइल या क्यों, लेकिन जैसा कि आप कहते हैं, कुछ विरोधाभासी - और भविष्य में "विषम व्यवहार" होने का खतरा है।

— ट्रिपएपाउंड

9

सुपर-सुपर-उपयोगकर्ता होने के बजाय, आप रूट को सीमित कर सकते हैं। देखें कि gnu / linux पर फ़ाइल अनुमतियाँ आदि सेट करने के विभिन्न तरीके क्या हैं
इसमें AppArmor और SELinux भी है।
और / या कॉन्फ़िगर करें sudo, ताकि आप पूरी जड़ विशेषाधिकार न दें। आप इसे सेट कर सकते हैं ताकि उपयोगकर्ता केवल पूर्व-सहमत आदेश चला सके, पूर्व-सहमत तर्कों के साथ।
रूट को प्रतिबंधित करने के लिए आप वर्चुअलाइजेशन का भी उपयोग कर सकते हैं:
- cgroups, नामस्थान, चेरोट आदि (docker यह करता है)
- एक्सईएन
- Virtualbox
यह भी देखें etckeeper: यह उपकरण संशोधन /etcनिर्देशिका को नियंत्रित करता है , और उपयुक्त के साथ सिंक्रनाइज़ करता है। डिफ़ॉल्ट रूप से यह सुरक्षित नहीं है, एक दुर्भावनापूर्ण इंस्टॉल इसे तोड़फोड़ कर सकता है, लेकिन आप इसे फायर-वाल बैकअप बैकअप रिपॉजिटरी में परिवर्तनों को धकेलने के लिए भी प्राप्त कर सकते हैं।
फायर-वाल बैकअप बैकअप रिपॉजिटरी के साथ सामान्य रूप से संशोधन नियंत्रण का उपयोग। यह आकस्मिक, जानबूझकर भ्रष्टाचार और हार्डवेयर विफलता के साथ मदद करता है।

फ़ायरवॉल बैकअप रिपॉजिटरी एक अलग मशीन, इंटरनेट पर, या एक अलग वर्चुअल मशीन (या वर्चुअल मशीन की मेजबानी) पर हो सकती है।

— Ctrl-Alt-delor
स्रोत

8

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

आप प्रतिबंधों को कितना स्थान देंगे, इसके आधार पर, कुछ स्थापित स्क्रिप्ट्स के टूटने की उम्मीद की जा सकती है।

एप्लिकेशन और उपयोगकर्ताओं को प्रतिबंधित करने के तरीकों के लिए, आप एक AppArmor या एक SELinux नीति लिख सकते हैं। ऐसी नीति जो अधिक समर्थित है, आपके वितरण पर निर्भर करती है: डेबियन आधारित को AppArmor के लिए बेहतर समर्थन है, जबकि फेडोरा / RHEL आधारित वितरण डिफ़ॉल्ट रूप से SELinux को सक्षम करते हैं।

AppArmor और SELinux दोनों श्वेत सूची नीतियों पर काम करते हैं, जिसमें विशिष्ट कार्यों की अनुमति देने (या अस्वीकार) के नियम हैं। नीतियाँ पर एक प्रक्रिया को लागू कर रहे हैं कार्यकारी , ठीक उसी प्रकार उपयोगकर्ताओं को किसी नीति पर अपनी प्रक्रिया पर लागू होती लॉग-इन है प्रतिबंधित किया जा सकता। एक अच्छी तरह से सोची गई नीति को दरकिनार नहीं किया जा सकता है (यदि कर्नेल कीड़े नहीं माने जाते हैं)। रूट (uid 0) के रूप में चल रही सीमित प्रक्रिया कॉन्फ़िगर नीति द्वारा प्रतिबंधित है और इसे तब तक परिवर्तित नहीं किया जा सकता जब तक कि नीति में स्पष्ट रूप से अनुमति नहीं दी जाती है।

AppArmor नीति भाषा एक इनकार नियम को परिभाषित करती है , जिसका उपयोग ब्लैकलिस्ट नीति बनाने के लिए किया जा सकता है । AppArmor के साथ शुरू करने के लिए एक अच्छी जगह है AppArmor मैन पेज , विकी और आपके वितरण में मौजूदा कॉन्फ़िगरेशन को देखना /etc/apparmor.d/।

SELinux विकि में भरपूर SELinux प्रशासन और विकास सामग्री उपलब्ध कराई गई है । SELinux संदर्भ नीति को github पर होस्ट किया गया है।

— sebasth
स्रोत

7

मुझे विश्वास नहीं हो रहा है कि किसी ने भी उपयुक्त उल्लेख नहीं किया है ...

कुछ साल पहले, माइक्रोसॉफ्ट ने एक पैच जारी किया था जिसने विंडोज 10 मशीनों को हमारे पुराने सांबा एनटी 4 डोमेन कंट्रोलर्स से बात करने से रोक दिया था। जब समस्या पाई गई, तो हमने वर्तमान संस्करण पर बने रहने के लिए सांबा पैकेज को पिन कर दिया, और फिर aptभी सही ढंग से कार्य किया।

एक पूर्ण डेबियन वॉकथ्रू प्रक्रिया को अच्छी तरह से समझाता है:

में /etc/apt/preferences(या एक नई फ़ाइल के नीचे /etc/apt/preferences.d/) है, जो पैकेज और संस्करण निर्दिष्ट करने के कुछ पाठ जोड़ें:

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

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

नोट: यह उत्तर मान रहा है कि आपको एक XY समस्या है

— कनाडाई ल्यूक पुनर्जीवित मोनाका
स्रोत

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

— mchid

इसके अलावा, मुझे लगता है कि यह एक XY समस्या का एक सा है, लेकिन Y यहाँ है "मैं कैसे जड़ को अनुमति देने से इनकार करता हूं जब जड़ सुपरसुसर है?"

— mchid

1

@ mchid यह रूट को अनुमति देने से इनकार करने के बारे में नहीं है, लेकिन रूट के रूप में चल रहे प्रोग्राम के लिए कुछ को अस्वीकार करना है।

— जॉन कीट्स

6

यह वास्तव में काफी सरल है।

रूट आपका "सुपर सुपर उपयोगकर्ता" है

"व्यवस्थापक" नामक एक खाता बनाएं और उसे रूट की सभी अनुमतियों को दें, जिसे आप नहीं चाहते हैं।

फिर बॉब नामक एक उपयोगकर्ता बनाएं, और उसे "व्यवस्थापक बनें"। सु या सूद का उपयोग करके।

अब आपके पास एक सामान्य उपयोगकर्ता (बॉब) एक सुपर उपयोगकर्ता है जो एडमिन स्टफ (व्यवस्थापक) और एक सुपर सुपर उपयोगकर्ता (रूट) कर सकता है।

यदि आप "रूट" नाम को किसी और चीज़ में बदलना चाहते हैं तो आप भी ऐसा कर सकते हैं। तकनीकी रूप से केवल उपयोगकर्ता आईडी (0) मायने रखती है।

— coteyr
स्रोत

यदि मेरे पास एक सामान्य उपयोगकर्ता (बॉब) था, तो एक सुपर उपयोगकर्ता जो सामान (एडमिन), और एक सुपर सुपर उपयोगकर्ता (रूट) कर सकता है, वह अभी भी सभी व्यवस्थापक सामग्री को पृष्ठभूमि प्रक्रियाओं, क्रोनोजर, और के साथ नहीं कर रहा है उपयोगकर्ता आईडी (0) के रूप में अन्य सामान?

— mchid

यदि आप उन्हें नहीं चाहते हैं तो नहीं। अधिकांश सेवाएँ आपको यह चुनने देती हैं कि उपयोगकर्ता क्या कार्य करता है। आप इसे सेट कर सकते हैं ताकि व्यवस्थापक उपयोगकर्ता एक है जो प्रक्रियाओं को चला रहा है। कुछ अपवाद हैं, लेकिन कई नहीं हैं।

— coteyr

क्या मुझे व्यक्तिगत रूप से उन सभी प्रक्रियाओं से गुजरना और सेट करना नहीं पड़ेगा?

— mchid

3

ऐसा तब होता है जब आप मानक सम्मेलनों को तोड़ने की कोशिश करते हैं। मुझे लगता है कि आपको एक * निक्स वातावरण में अनुमतियों के सिस्टम के व्हाट्स और व्हाट्सएप को बेहतर ढंग से समझना होगा।

— शौना

2

मैं शौना से सहमत हूँ, आपको * निक्स अनुमति प्रणाली की बुनियादी समझ की कमी लगती है। यह बहुत शक्तिशाली है, लेकिन यह खिड़कियों जैसा कुछ नहीं है।

— coteyr

3

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

असली सवाल आप पूछना चाहते हैं:

क्या एपीटी को विशिष्ट फ़ाइलों को स्थापित करने से रोकने का कोई तरीका है?

यह उस चीज़ से पूरी तरह से अलग है जो आप कई स्तरों पर पूछ रहे हैं।

अब, उस प्रश्न के रूप में, मैं स्वयं 100% निश्चित नहीं हूं, लेकिन मुझे पता है कि कई अन्य पैकेज प्रबंधकों के पास विशिष्ट फ़ाइलों को स्थापित होने से रोकने के लिए विकल्प हैं (उदाहरण के लिए, गेंटू के पोर्टेज सिस्टम में विकल्प है INSTALL_MASK=, जो वास्तव में शेल को स्वीकार करता है -स्टाइल मैचिंग पैटर्न ऑफ़ थिंग्स टू न इनस्टॉल)। मैं शर्त लगाने के लिए तैयार हूं कि एपीटी (या संभवतः स्वयं dpkg) के लिए ऐसा विकल्प मौजूद है।

— ऑस्टिन हेममेलगरन
स्रोत

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

— mchid

dpkg- divert

— mchid

1

बैकअप कॉपी सुरक्षित स्थान पर रखें। किसी भी स्थापित / अद्यतन के बाद, तुरंत उस बैक-अप से विशिष्ट फ़ाइलों को बदलें। इस प्रकार, कोई त्रुटि नहीं स्थापित करने के लिए लेकिन आप अभी भी उस फ़ाइल को वापस प्राप्त करते हैं जिसे आप रखना चाहते थे।

— WGroleau
स्रोत

1

माउंटेड ड्राइव से काम करें

ध्यान दें कि यह ज्यादातर एक वैचारिक उत्तर है, लेकिन मुझे लगता है कि यह काम करना चाहिए और जो आप प्राप्त करना चाहते हैं उसके साथ आत्मा में होना चाहिए।

सिस्टम X को आपकी कार्य प्रणाली और सिस्टम Y को एक अन्य प्रणाली होने दें जिसे आप नियंत्रित करते हैं

Y से X में ड्राइव के रूप में एक निर्देशिका माउंट करें
अधिकारों को इस तरह से सेट करें कि एक्स के रूट उपयोगकर्ता के पास इस घुड़सवार ड्राइव में कुछ अपवादों के साथ सब कुछ पर अधिकार हैं

अब आपके पास आपकी 'वर्किंग रूट' है, जो लगभग सब कुछ कर सकती है, और आपके पास आपका 'सुपर रूट' है, सिस्टम Y का वास्तविक रूट अकाउंट, जो सब कुछ कर सकता है।

— डेनिस जहरुद्दीन
स्रोत

मुझे यह विचार पसंद है, हालांकि, मैं इसे एक रनिंग सिस्टम पर करना चाहूंगा।

— mchid

1

आप एक प्रकार -1 एक्स हाइपरवाइज़र जैसे एक्सपी हाइपरवाइज़र चला सकते हैं और जो आपके नियमित ओएस को एक वर्चुअलाइज्ड अतिथि के रूप में होस्ट कर सकता है। हाइपरविजर वर्चुअल गेस्ट OS को रूट से "गहरा" स्तर पर नियंत्रित करता है क्योंकि इसका वर्चुअल (वर्चुअल) हार्डवेयर पर नियंत्रण होता है, जिस पर गेस्ट ओएस चलता है।

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

मेरी समझ है कि यह दृष्टिकोण शायद ओवरकिल है

— नाथन स्मिथ
स्रोत

एक अतिथि वीएम में कुछ भी करने की इच्छा रखने वाले उपयोगकर्ता को एक हाइपरवाइजर रूट अनुमति से कैसे रोकता है?

— fpmurphy

यह उत्तर ठीक शुरू होता है, लेकिन फिर व्याकरणिक रूप से भटक जाता है (यह तब गलत तरीके से चारों ओर पढ़ रहा है, या कम से कम अस्पष्ट है)। मैंने एक फिक्स किया।

— ctrl-alt-delor-Sepor

1

@ fpmurphy1 एक हाइपरवाइजर रूट यूजर या गेस्ट ओएस के किसी अन्य हिस्से पर मनमाना प्रतिबंध लगाने के लिए सिस्टम कॉल, पॉलिसी लागू कर सकता है, आदि। शायद मेरा जवाब अच्छा नहीं है क्योंकि यह बहुत ज्यादा काम है जब तक कि आपको कुछ वास्तविक उद्यम का उपयोग मामला या कुछ और नहीं मिला ...

— नाथन स्मिथ

@ ctrl-alt-delor आपके फिक्स के लिए धन्यवाद, लेकिन मुझे नहीं लगता कि व्याकरण समस्या थी। मैंने स्पष्ट किया कि मेरा कहने का मतलब क्या है, और मैं इस प्रतिक्रिया की सराहना करता हूं कि मेरे विचार पहले स्पष्ट नहीं थे

— नाथन स्मिथ

1

@ fpmurphy1 अतिथि के भीतर आपके पास पूरी जड़ है। हालांकि यह मेजबान पर जड़ के समान नहीं है। इसलिए यह मेजबान रूट की तुलना में कम जड़ है। डॉकर चीजों को अधिक एकीकृत करने की अनुमति देगा, लेकिन फिर भी रूट पर प्रतिबंध लगाएगा।

— ctrl-alt-delor-Sepor

1

इस प्रकार के लक्ष्य को प्राप्त करने की एक वैकल्पिक विधि के साथ-साथ डॉकर और lxd जैसे टूल पर भी cgroups और Linux नामस्थानों पर एक नज़र डालें ।

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

— SMW
स्रोत

0

स्थापना रद्द करें `sudo`

कैसे के बारे में स्थापना रद्द करने sudoऔर /bin/suकरने के लिए /bin/false? यह सुनिश्चित करने के साथ कि rootआप लॉगिन नहीं कर सकते हैं sshऔर आपने सिस्टम को बंद कर दिया है।

यह rootसुपर * सुपर उपयोगकर्ता बनाता है, और बाकी सब उसी के अधीनस्थ हैं।

अद्यतनों के दौरान प्रतिस्थापित फ़ाइलों के लिए, बस कोई अद्यतन न करें। अधिक वास्तविक रूप से, फ़ाइलों की अनुमतियाँ बदलें 440या 444तो उन्हें लिखा नहीं जा सकता है। या उन्हें गिट रिपॉजिटरी में डाल दिया जाए ताकि वे ओवरराइट हो जाएं, तो उसे वापस लाया जा सके।

— user176717
स्रोत

आप देखते हैं, मैं अभी भी अपडेट करना चाहता हूं और मैं अभी भी रूट को बहुत अधिक सामान करना चाहता हूं जो रूट सामान्य रूप से करता है। हालाँकि, मैं यह कहना चाहता हूं कि वह "अरे ऐसा मत करो" या "नहीं, तुम ऐसा नहीं कर सकते हो" जैसा कि माता-पिता का अधिकार संतान के लिए सक्षम होगा। जैसा कि अभी है, रूट मेरे सिस्टम पर माता-पिता के अधिकार की तरह है और सभी छोटे बच्चे कहते हैं "माँ क्या मैं?" जब वे sudo का उपयोग करते हैं। यह ठीक है। हालांकि, इस ग्रह पर लगभग हर व्यक्ति किसी न किसी की संतान है। ऐसा लगता है कि यहाँ कुछ जवाब ऐसे हैं जैसे एक बच्चा आत्म जागरूकता से पहले होगा जब उन्हें एहसास नहीं होता है

— mchid

। । । वह दादी और दादा माँ और पिताजी की माँ और पिता हैं। मैं दादाजी से अपने सिस्टम में लाइव आने के लिए कहना चाहूंगा क्योंकि अभी, रूट घर के पिताजी हैं और दादाजी पिताजी को बता सकते हैं कि क्या करना है क्योंकि दादाजी के पिता हैं :)

— mchid

ऐसा लगता है कि आपने सूद शक्तियों के साथ बहुत सारे लोगों को जोड़ा है। sudoersफ़ाइल को समायोजित करें ताकि केवल चयनित उपयोगकर्ता ही पूर्व-चयनित आदेशों को sudo कर सकें।

— user176717

मेरे पास केवल sudoers फ़ाइल में रूट सहित दो उपयोगकर्ता हैं। मैं यह समझाने के लिए एक उपमा का उपयोग करने की कोशिश कर रहा था कि कैसे कुछ लोग मेरे प्रश्न को नहीं समझ पा रहे हैं और मैं क्या हासिल करना चाहूंगा।

— mchid

ऐसा लगता है कि लोगों को ऐसा लगता है कि कोई भी उपयोगकर्ता उसी तरह से जड़ से ऊंचा नहीं हो सकता है जिस तरह से एक बहुत छोटे बच्चे को लगता है कि उसके माँ और पिताजी का कोई माता-पिता नहीं हो सकता है। इसके अलावा, मैं नीचे नहीं था।

— mchid

माउंटेड ड्राइव से काम करें

स्थापना रद्द करें sudo

स्थापना रद्द करें `sudo`