यदि उपयोगकर्ता सभी आदेशों तक पहुंच प्रदान करता है तो सुडो सीधे सु का उपयोग करने से कैसे सुरक्षित है?


40

इसलिए मैं उपयोग करने के बीच के अंतरों में पढ़ रहा हूं suऔर sudo, और सभी को sudoयह समझ में आ रहा है कि दृष्टिकोण स्वयं रूट खाते तक पहुंचने की अनुमति देने से अधिक सुरक्षित है। वे कहते हैं कि रूट खाते से आप अपने पूरे सिस्टम को सिर्फ एक कमांड से तोड़ सकते हैं। यह मैं समझता हूं। लेकिन सिस्टम पर बनाए गए प्रारंभिक उपयोगकर्ता के पास भी sudo के उपयोग से सभी कमांड तक पहुंच होती है। यह मैं दौड़कर पता लगा सकता हूं su -l। यदि यह मामला है, तो मैं बस sudo <game-ending command>अपने सिस्टम को बर्बाद करने के लिए चला सकता हूं। तो यह दृष्टिकोण कैसे बेहतर या सुरक्षित है फिर मुझे सुपर उपयोगकर्ता खाते तक सीधे पहुंचने की अनुमति देता है? मैं सभी एक ही कमांड चला सकता हूं ...

क्या ऐसा इसलिए है क्योंकि sudoकमांड लाइन का उपयोग करते हुए मैं स्पष्ट रूप से कंप्यूटर को बता रहा हूं कि मुझे लगता है कि मुझे पता है कि मैं क्या कर रहा हूं? क्या उन्हें लगता है कि जब तक वे स्पष्ट रूप से ऐसा नहीं कहेंगे, तब तक लोग भूल जाएंगे कि वे सुपर उपयोगकर्ता खाते में हैं।

लोग यह भी कहते हैं कि अगर सिस्टम में किसी विदेशी द्वारा समझौता किया गया और दर्ज किया गया, तो रूट अकाउंट के तहत होने से उन्हें मेरी प्रणाली के लिए भयानक काम करने की अनुमति मिलेगी। लेकिन यह मुझे लगता है कि अगर उनके पास पहले से ही मेरे खाते तक पहुंच है, और मेरे पासवर्ड को जानते हैं, तो वे सूडो का उपयोग करके और मेरे पासवर्ड दर्ज करके इन भयानक कामों को कर सकते हैं क्योंकि उन्हें सुपर उपयोगकर्ता के पासवर्ड को जानने की आवश्यकता नहीं है। मुझे यहाँ क्या नहीं मिल रहा है?



2
इस प्रश्न को बनाने के लिए धन्यवाद, इसलिए अब लोगों को दिखाने के लिए कुछ है जो सूडो को सुरक्षित रखते हैं लेकिन इसे उचित नहीं ठहरा सकते हैं।
user253751

जवाबों:


40

व्यक्तिगत रूप से मैं इसे अधिक सुरक्षित नहीं मानता हूं और अधिकांश लाभ (सूदो के) एक बहु उपयोगकर्ता प्रणाली पर हैं। एक एकल उपयोगकर्ता प्रणाली पर यह शायद एक धोने है।

लाभ हैं (कोई विशेष क्रम में):

  • सुडो में बेहतर लॉगिंग है। sudo प्रत्येक कमांड को लॉग करता है।
  • sudo बारीक अनाज नियंत्रण की अनुमति देता है। एक कुछ को रूट एक्सेस देने के लिए sudo को कॉन्फ़िगर कर सकता है लेकिन सभी कमांड को नहीं।
  • sudo लॉगिन पासवर्ड का उपयोग करता है। यह रूट पासवर्ड देने की सुरक्षा करता है (जैसा कि आप su के साथ करेंगे) और ऊपर के बिंदु से संबंधित है जो महीन दानेदार नियंत्रण / रूट तक पहुंच से संबंधित है।
  • उबंटू में, डिफ़ॉल्ट रूप से, रूट खाता लॉक है। यह पटाखे को बंद करने के लिए लॉग इन (ssh के माध्यम से दूरस्थ) के रूप में करता है, उन्हें एक उपयोगकर्ता नाम और एक पासवर्ड दोनों का अनुमान लगाना होगा। यदि रूट खाता लॉक नहीं है, जैसा कि su के मामले में है, तो उन्हें केवल रूट के पासवर्ड को क्रैक करना होगा।
  • sudo -iअपने उपयोगकर्ता से रूट के पर्यावरण चर को अलग करने के लिए शायद सबसे अच्छा तरीका है। यह समय-समय पर आता है लेकिन मध्यम रूप से गूढ़ है। Https://help.ubuntu.com/community/RootSudo#Special_notes_on_sudo_and_sss देखें
  • कुछ लोग महसूस करते हैं कि हर कमांड के पहले सुडो टाइप करने के बाद वे रूट के रूप में चलाना चाहते हैं या सूडो टाइम आउट होने से उन्हें रुकने और अधिक स्पष्ट रूप से सोचने और उनकी त्रुटियों को कम करने या गलत कमांड चलाने की अनुमति मिलती है। यदि ऐसा करने से आपको मदद मिलती है तो यह एक फायदा भी होगा।

संभवतः अधिक लाभ हैं, लेकिन, वे प्रमुख हैं, आईएमएचओ।

यह भी देखें - https://help.ubuntu.com/community/RootSudo

आपके कुछ अन्य विचारों का जवाब देने की कोशिश करने के लिए:

  • जब तक आप पासवर्ड जानते हैं तब तक सू या सूडो के बारे में कुछ भी नहीं है जो आपको दुर्भावनापूर्ण कोड चलाने से रोकता है। न तो ज्यादा सुरक्षित है और न ही बेहतर है।
  • पटाखे कई तरीकों के माध्यम से शेल एक्सेस प्राप्त कर सकते हैं। जब आप सुरक्षा नोटिस में "रन मनमाना कोड" देखते हैं - https://usn.ubuntu.com/usn/ - इसका मतलब है कि एक पटाखा चला सकता है / बिन / बैश या कोई अन्य कोड। इस प्रकार, एक पटाखा, विभिन्न कारनामों के माध्यम से, आपके लॉगिन नाम या पासवर्ड को जाने बिना शेल एक्सेस प्राप्त कर सकता है। इसके साथ न तो सुडो या सु मदद करता है।
  • यदि किसी पटाखे में शेल एक्सेस है तो वे रूट एक्सेस के बिना बहुत नुकसान कर सकते हैं। उदाहरण के लिए रैंसमवेयर जो आपके सभी व्यक्तिगत डेटा को एन्क्रिप्ट करता है।
  • यदि किसी पटाखा के पास रूट एक्सेस के साथ किसी खाते में शेल एक्सेस है, तो su या sudo के माध्यम से, क्रैकर इस चर्चा के दायरे से परे कई तरीकों से रूट एक्सेस प्राप्त कर सकता है। इस संबंध में न तो सुडो या सु बेहतर है।

इसलिए जब आपने सुडो के साथ समस्याओं या खामियों को देखा है, तो सु की भी ठीक वैसी ही कमजोरियाँ हैं और उन पहलुओं में सुडो से बेहतर नहीं है, IMHO


सभी उपयोगकर्ताओं को पावर (पॉवरऑफ़ और रिबूट) को अनुमति देने के लिए ऑप्टऑट अपचयन पर नियंत्रण करने की अनुमति देना अच्छा होगा, बजाय कि सुडो एंट्रीज़ या समूह नाम रखने के।
mckenzm

8
मेरा मानना ​​है कि सबसे बड़ी बात यह है कि प्रत्येक कमांड को सुपरसुअर अनुमतियों की आवश्यकता के रूप में उचित ठहराना है। मैंने लिनक्स के साथ अपने शुरुआती अनुभव में पाया कि मैं हमेशा कम से कम एक टर्मिनल में रूट के रूप में रनिंग करना चाहता था क्योंकि मैंने सिस्टम के साथ टिंकर किया था। दुर्भाग्य से, गलतफहमी या गलत व्यवहार द्वारा टर्मिनल पर एक विनाशकारी आदेश जारी करना बहुत आसान है। यदि वह 'मूल टर्मिनल' में था, तो बैकअप या पुनर्स्थापना से इसे बहाल किया जा सकता था। सूदो ने कई बार मेरी रक्षा की है!
rolinger

14
रूट पासवर्ड से समझौता न करना शायद सुडो का सबसे बड़ा लाभ है। बिना किसी रहस्य का खुलासा किए आप रूट की अनुमति दे सकते हैं।
थोरबजोरन रेव एंडरसन

न केवल आप आदेशों को प्रतिबंधित कर सकते हैं, बल्कि आप निर्दिष्ट तर्कों को भी प्रतिबंधित कर सकते हैं। लेकिन मैं असहमत हूं कि जड़ को बंद किया जाना कुछ भी नहीं है; क्योंकि आप ssh को रूट लॉगिन की अनुमति नहीं देने के लिए कॉन्फ़िगर कर सकते हैं। सु बनाम सूडो के साथ कुछ और भी है: सूदो आप अपने उपयोगकर्ता पासवर्ड का उपयोग करते हैं जो कि समझौता करने के लिए एक कम पासवर्ड है और यह आमतौर पर एक अच्छी बात नहीं है। इस दुनिया में सब कुछ की तरह कुछ के बारे में जाने के लिए अलग-अलग तरीके हैं और इसका मतलब यह नहीं है कि एक तरीका दूसरों की तुलना में 100% अधिक सही है यदि कभी भी। फिर प्राथमिकताएं हैं।
प्रिएफ्टन

लेकिन ओटोह अगर यह एक से अधिक उपयोगकर्ता की आवश्यकता है रूट एक्सेस की आवश्यकता है (जो कुछ ऐसा नहीं है जो मुझे मिल जाएगा क्योंकि यह सिर्फ इतना है - अच्छी तरह से यह एक गर्म चर्चा है) तो सुडो का वहां एक फायदा है।
प्रिएफ्टन

10

कल्पना कीजिए कि आपके पास कुछ जटिल करने के लिए 20 मिनट हैं। आप थोड़े भूखे हैं और आपको दौड़ना है। "चलो सु का उपयोग करें" आप कहते हैं। "यह कुछ समय बचाएगा" आपका तर्क है।

दुर्घटना से आप टाइप करते हैं

rm -rf /*

के बजाय

rm -rf ./*

आपका सिस्टम अब अपने आप को ब्रिक कर रहा है और आपके पास आपकी समय सीमा तक 10 मिनट है।

यदि आप स्पष्ट रूप से चुनते हैं जब आपको रूट की आवश्यकता होती है, तो आप ऐसा होने की संभावना को कम कर सकते हैं। रूट की आवश्यकता नहीं हो सकती rm -r ./*है इसलिए इसका उपयोग क्यों करें? जोखिम क्यों लेते हैं?

यही "सुरक्षा" का मतलब यहाँ है। उपयोगकर्ताओं (सभी उपयोगकर्ताओं, न केवल शुरुआती) के जोखिम को कम करना एक घातक गलती है।

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

सुरक्षा के लिहाज से कुछ ऐसे सामान हैं जो सुडो के लिए भी बेहतर हैं। जैसा @Panther कहते हैं - लॉगिंग, प्रतिबंध, रूट पासवर्ड SPOF, आदि)


4
नरक, आपको उस समय तक इंतजार करने की आवश्यकता नहीं है यदि आप बस करते हैं ... chown -R nobody:nobody /या यहां तक chown -R nobody ../कि जड़ के रूप में। chmodबेशक पुनरावर्ती मोड में भी ऐसी ही समस्याएं हैं। लेकिन जो सबसे अच्छा बिंदु आप बनाते हैं, वह यह है कि आपको केवल तभी रूट होना चाहिए जब आपको इसकी आवश्यकता हो; कम विशेषाधिकार आपके लॉगिन सामान्य उपयोग के लिए बेहतर है।
प्रिएफ्टन

2
प्रोग्रामिंग के लिए +1 जब आप भूख से मर रहे हैं।
abhicantdraw

4
तो, यह कैसे अलग है sudo? आप फिर से लिखने और उछालने के sudo rm -rf /*बजाय sudo rm -rf ./*
ilkachachu

2
@ilkachachu वास्तविक आदेश के संदर्भ में, यह क्या होता है के लिए न्यूनतम अंतर बनाता है। लेकिन आपको स्पष्ट रूप से यह बताना होगा कि आप इसे रूट के रूप में करना चाहते हैं। यही तो बात है। सुरक्षा जोखिम प्रबंधन के बारे में है। बेशक आप अभी भी सिस्टम को ईंट कर सकते हैं। लेकिन जितनी कम बार आपके पास रूट विशेषाधिकार होते हैं, उतनी ही कम गलती करने की संभावना होती है। सुरक्षा सभी संभावनाओं को कम करने के बारे में है।
dijksterhuis

2
@ilkkachu क्योंकि आप टाइप नहीं करेंगेsudo rm -rf ./* । संभवतः आपने वर्तमान निर्देशिका में सामान तक पहुंच लिखी है, इसलिए आपको उस कमांड के लिए sudo की आवश्यकता नहीं है। तो ऊपर जा रहा है typoed आदेश समाप्त हो जाती है rm -rf /*, जिनमें से "अनुमति अस्वीकृत" संदेश, बताता है कि आप की जरूरत है एक लंबी स्ट्रिंग पैदावार ctrl-cसे पहले यह सामान आप वास्तव में नष्ट कर सकते हैं करने के लिए हो जाता है, के बजाय सिर्फ में सब कुछ को हटाने /bin, /boot, /dev, और के आधे /etcसे पहले आपको कुछ गलत होने का एहसास है।
रे

9

मैं अन्य उत्तरों में थोड़ा ऐतिहासिक परिप्रेक्ष्य जोड़ना चाहता हूं। दुर्भाग्य से, मेरे पास यूज़नेट चर्चाओं और पत्रिका लेखों की अपनी यादों के अलावा कोई स्रोत तैयार नहीं है।

कुछ समय पहले, 1990 के दशक में, वितरण ने आपके स्वयं के हार्डवेयर पर लिनक्स को स्थापित करना आसान बना दिया था, यहां तक ​​कि बहुत अधिक कंप्यूटर ज्ञान भी नहीं था। इस प्रकार, लिनक्स ने अधिक से अधिक लोगों को आकर्षित करना शुरू कर दिया, जो आश्चर्यजनक रूप से सिस्टम प्रशासक के रूप में पहले ड्रिल नहीं किया गया था कुछ यूएन * एक्स बोली। इसके बजाय, कई विंडोज 95/98 जैसे (एकल उपयोगकर्ता) सिस्टम के लिए उपयोग किए गए थे। और उन्होंने सीखा कि अधिकांश लिनक्स सिस्टम प्रशासन कार्यों ने उस अजीब "रूट" खाते के तहत काम करना आवश्यक बना दिया।

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

तो, उबंटू रास्ते के sudoकुछ फायदे हैं ( पैंथर द्वारा पहले से सूचीबद्ध लोगों के अलावा )।

  • आप सीधे मूल खाते में प्रवेश नहीं कर सकते । ² :-)
  • स्थापना प्रक्रिया आपसे एक (अतिरिक्त) रूट पासवर्ड नहीं मांगेगी, आपको केवल एक (आपके उपयोगकर्ता का) पासवर्ड चाहिए।
  • sudoआपके क्रेडेंशियल्स को कैश करता है, इसलिए कई एडमिन कमांड के लिए अनुक्रम में, आपको केवल एक बार अपना पासवर्ड दर्ज करना होगा (इसके विपरीत su)। यह रूट विशेषाधिकारों के साथ एक शेल या एक नया टर्मिनल खोलने के आग्रह को कम करता है ।
  • और उपयोगकर्ताओं को ऑनलाइन और दस्तावेज़ीकरण में यह बताना आसान बनाता है कि उन्हें कौन से आदेशों को व्यवस्थापक के रूप में दर्ज करना है और कौन सा नहीं

Not और जो लोग इसे स्वयं करने का साहस नहीं कर रहे थे, उनके लिए स्थापित पक्ष थे।
² लेकिन सामान्य उपयोगकर्ता के रूप में लॉग इन करने के बाद आप रूट कमांड या रूट शेल का उपयोग कर सकते हैं । Of लेकिन आप निश्चित रूप से जानते हैं कि आपको बस इंटरनेट से कमांड कॉपी और पेस्ट नहीं करना चाहिए , है ना?sudo -isudo su - root


क्या आप उबंटू में कह रहे हैं कि आप ऐसा नहीं कर सकते: sudo su -या sudo su - root? क्योंकि मैंने इसी तरह के दावों को देखा है जैसे कि MacOS X की जड़ नहीं है, लेकिन यह पूरी तरह से गलत है जब किसी को केवल पहली कमांड करने की जरूरत है ...
Pryftan

2
बेशक एक रूट खाता है। मैंने कहा कि आप "सीधे लॉगिन" नहीं कर सकते हैं, जिसका अर्थ है कि आप rootलॉगिन प्रॉम्प्ट या एक्स लॉगिन डायलॉग पर उपयोगकर्ता और एक पासवर्ड दर्ज नहीं कर सकते हैं और अपना सत्र रूट के रूप में शुरू कर सकते हैं लेकिन आप अपनी एक कमांड का उपयोग कर सकते हैं (मुझे पसंद है sudo -iकि यह छोटा है और मैं आलसी हूं) रूट शेल प्राप्त करने के लिए।
डब्बू

1
कृपया मेरी टिप्पणी को फिर से पढ़ें :) मैंने कहा कि कुछ का कहना है कि MacOS X का रूट खाता नहीं है, लेकिन वास्तव में यह करता है और इसने मुझे यह याद दिलाया (मैंने इसे उबंटू में कोई रूट खाता नहीं होने के बराबर कहा था)। लेकिन सभी के लिए मुझे पता है कि उबंटू में देवता काफी पागल थे जो सूडो को पैच करने के लिए अनुमति नहीं देते थे, इसलिए मेरा सवाल था।
20

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

हाँ। मुझे पता है कि :) मैं यह नहीं कह रहा था कि यह गलत था या नहीं। मैं कह रहा था कि इसने मुझे कुछ लोगों की याद दिलाई है जो कुछ लोग कहते हैं लेकिन कहने में गलत हैं। इसलिए उस हिस्से को बोल्ड बनाना।
प्रियेफ़टन

2

दशकों से ssh के माध्यम से रूट लॉगिन को निष्क्रिय करना संभव है। रूट खाते को निष्क्रिय करने और लोगों को सब कुछ बनाने का उबंटू तरीका नौटंकी से ज्यादा कुछ नहीं है। बस "सुडो-एस" और आपके पास एक रूट शेल है। Ssh के माध्यम से रूट लॉगिन को अक्षम करें और इसे वहां छोड़ दें।


8
... उस नोट पर, केवल किसी भी ssh लॉगिन के लिए, केवल रूट खाता नहीं, महान अभ्यास है।
रैकैंडबनमैन

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

0

कॉन्फ़िगरेशन पर निर्भर करता है, sudo <game ending command>जरूरी काम नहीं करेगा। बेशक, यदि sudoersकॉन्फ़िगरेशन "उपयोगकर्ता ALL = (ALL) ALL" पढ़ता है , तो sudoकोई अतिरिक्त सुरक्षा प्रदान नहीं करेगा। हालाँकि, आपको विशेष रूप से नए पैकेजों को स्थापित करने और जैसे खतरनाक आदेशों को छोड़ने की जरूरत है, विशेषाधिकृत कमांडों की सूची निर्दिष्ट कर सकते हैं rm

इस तरह से आप सभी कमांड चला सकते हैं यदि आप लॉगिन करते हैं root, लेकिन चूंकि आपको केवल कभी-कभी इसकी आवश्यकता होगी, इसलिए चलने का जोखिम <game ending command>काफी कम हो जाएगा।


1
और आज्ञाओं के लिए विशिष्ट तर्क, भी।
प्रिएफ्टन

1
और प्रति उपयोगकर्ता के बजाय प्रति समूह। समूहों का उपयोग करना बहुउपयोगी वातावरण में अमूल्य है स्टाफ आ सकता है और जा सकता है और जहां आपको विशिष्ट भूमिकाओं की आवश्यकता हो सकती है।
पैंथर

0

यह sudo आपको केवल कुछ आदेशों की अनुमति देता है su पर sudo का एकमात्र लाभ नहीं है।

ज्यादातर दुकानों में, यह सबसे महत्वपूर्ण लाभ भी नहीं है।

सुडो के साथ, आप जानते हैं कि किसने एक विशेष कमांड का प्रदर्शन किया।

अब शायद यह आपके लिए मायने नहीं रखता। उदाहरण के लिए, आप अपने कंप्यूटर के एकमात्र उपयोगकर्ता हो सकते हैं। यदि ऐसा है, तो sudo संभवतः su से बेहतर नहीं है।

लेकिन बहुत सारे मेजबानों के पास एक से अधिक व्यवस्थापक हैं।

sudo तब बहुत उपयोगी हो जाता है क्योंकि अगर कोई गलत काम करता है, sudo आपको बता देता है कि यह किसने किया।

यह आपको समझने की अनुमति देता है कि त्रुटियां क्यों हुईं, और लोगों को पुनरावृत्ति से रोकने के लिए या यदि आवश्यक हो, तो किसी से उपकरण हटाने के लिए लोगों को शिक्षित करने के लिए।

एक बोनस के रूप में, जब लोग जानते हैं कि उनके कार्यों को रिकॉर्ड किया गया है, तो वे अक्सर थोड़ा अधिक सावधान रहते हैं।

सूडो बिल्कुल सही नहीं है।

यदि दो लोग एक ही समय में "सुडो श" करते हैं, तो एक या दूसरे को कमांड देना मुश्किल हो सकता है।

और एक दुर्भावनापूर्ण व्यवस्थापक हमेशा लॉग को हटा या संपादित कर सकता है - हालाँकि ऐसा करना हमेशा उतना आसान नहीं होता जितना कि लोग सोचते हैं, खासकर यदि आपके पास केंद्रीय लॉगिंग है।

मूल प्रश्न में पहचाने जाने वाले सभी कारणों के लिए सुडोल एक मूर्ख या दुर्भावनापूर्ण कार्रवाई को रोक नहीं सकता है।

लेकिन यह आपको पुनरावृत्ति को रोकने का एक बेहतर मौका देता है।


1. केवल अगर आप इसे ठीक से कॉन्फ़िगर करने के लिए समय लेते हैं। जो डिफ़ॉल्ट उबंटू प्रणाली नहीं करता है (और ऐसा नहीं कर सकता है)। 2. केवल अगर उपयोगकर्ता के पास लॉग-पोस्ट को संपादित करने का कोई तरीका नहीं है, जो कि वे तब तक कर सकते हैं जब तक कि वे जो कमांड चला सकते हैं वे सीमित हैं। (यह डिफ़ॉल्ट उबंटू उपयोग के मामले में नहीं है)
ilkkachu

@ilkkachu, हालांकि आपके कुछ अच्छे बिंदु हैं, लेकिन आपका तर्क यहाँ कोई मतलब नहीं है। बिंदु डिफ़ॉल्ट सेटिंग्स नहीं है, यह बिंदु यह है कि कॉन्फ़िगर करना और ट्यून सुडो को ठीक करना संभव है। आप इन तरीकों से कार्य करने के लिए su को कॉन्फ़िगर नहीं कर सकते हैं। सु सब है या नहीं, कमांड्स को सीमित करने का कोई तरीका नहीं है और यह बात दीगर है कि सुडोल बेहतर लॉगिंग प्रदान करता है। पटाखा प्रणाली में कोई पटाखा क्या कर सकता है और क्या नहीं, इसके खिलाफ न तो सू या सूडो कोई सुरक्षा प्रदान करते हैं और न ही किसी ने इस तरह से सूडो को बाहर रखा। सामान्य दिनों में दिन के संचालन के लिए सूडो लॉग का बहुत महत्व है।
पैंथर

@Panther, ठीक है, प्रश्न शीर्षक कहता है "... यदि उपयोगकर्ता को सभी आदेशों तक पहुंच प्रदान की गई है?" इसलिए मैंने मान लिया कि वे सामान्य डिफ़ॉल्ट उबंटू कॉन्फ़िगरेशन का मतलब है जहां sudoसब कुछ की अनुमति देता है। ज़रूर, आप इसे कमांड को सीमित करने के लिए कॉन्फ़िगर कर सकते हैं जिसे एक उपयोगकर्ता को चलाने की अनुमति है, लेकिन मुझे नहीं लगता कि सवाल में ऐसा मामला है।
ilkachachu

उत्तर का विस्तार।
बेन अवेलिंग

@ilkkachu - मेरे उत्तर को फिर से पढ़ें "व्यक्तिगत रूप से मैं इसे अधिक सुरक्षित नहीं मानता हूं और अधिकांश लाभ (sudo के) एक बहु उपयोगकर्ता प्रणाली पर हैं। एकल उपयोगकर्ता प्रणाली पर शायद यह एक धोना है।" फिर मैंने सुडो के अन्य फायदों के बारे में बताया, जिनमें से एक यह है कि यह विन्यास योग्य है।
पैंथर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.