जब उबंटू एक व्यवस्थापक उपयोगकर्ता का पासवर्ड पूछता है, तो यह कैसे तय करता है कि किस प्रशासनिक उपयोगकर्ता को पूछना है?

Question

मैं एक उबंटू (10.10) मशीन स्थापित कर रहा हूं जिसका उपयोग कई लोग करेंगे। यह एक छोटे से कार्यालय में एक साझा मशीन है। इसकी प्राथमिक भूमिका वर्चुअलबॉक्स के साथ वर्चुअल मशीनों की मेजबानी कर रही है और सांबा के साथ फाइलें परोस रही है।

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

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

संक्षेप में:

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

यहाँ वांछित स्थिति लाने के लिए मुझे कौन से विन्यास परिवर्तन की आवश्यकता है?

Comments

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

— ऑक्सीविसी

एक त्वरित Googling मुझे बताता है कि आप इसे बहुत ही sudoersफ़ाइल से करते हैं, आप अधिक जानकारी के लिए यह मैनपेज देख सकते हैं ।

— ऑक्सीविसी

मैंने माना कि जब मैं संपादन कर रहा था sudoers: सुरक्षा चिंताओं के कारण यह पहला सहारा नहीं है। इसके अलावा enzotib का जवाब देखें - समस्या का हिस्सा sudoऔर पॉलिसीकीट के बीच का भ्रम था ।

— ब्रिगिड मैकडॉनेल

Answer 1

सबसे पहले यह बताना चाहिए कि दो अलग - अलग तंत्रों के माध्यम से गैर-रूट उपयोगकर्ता के लिए विशेषाधिकार प्राप्त कार्यों की अनुमति है।

1. sudo

2. PolicyKit

पहले एक का उपयोग तब किया जाता है जब आप स्पष्ट रूप से sudoया एक मेनू आइटम के साथ एक कमांड चलाते हैं जिसका कमांड gksu(जैसे सिनैप्टिक पैकेज मैनेजर ) के साथ लिपटा होता है ।
इस मामले में आवश्यक पासवर्ड चालान उपयोगकर्ता का है, आमतौर पर उपयोगकर्ता लॉग इन करता है।

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

आप छोटे काले त्रिकोण और लेबल विवरण से PolicyKit की पहचान कर सकते हैं । जैसा कि आप देख सकते हैं, यदि एक से अधिक उपयोगकर्ता adminसमूह में हैं, तो आप उस सूची से चुन सकते हैं जिसे उपयोगकर्ता प्रमाणीकरण के लिए उपयोग करना है।

यह सब देखते हुए, दोनों sudoऔर PolicyKit अधिक जटिल हैं, जो प्राप्त किए जा सकने वाले कॉन्फ़िगरेशन के संबंध में हैं: आप उस कार्रवाई को कॉन्फ़िगर कर सकते हैं जिसे पासवर्ड के बिना निष्पादित किया जा सकता है, किसी विशेष उपयोगकर्ता या समूह द्वारा निष्पादित किया जा सकता है, आदि।

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

जब अनुप्रयोग द्वारा उपयोग किया जाने वाला तंत्र है sudo(GUI के माध्यम से किए गए व्यवस्थापक कार्यों के लिए यह लगातार कम होता जा रहा है), आपके पास प्रमाणीकरण के लिए उपयोगकर्ता को चुनने का कोई तात्कालिक और सरल साधन नहीं है।

Comments

मुझे ऐसा लगता है कि मुझे अब स्थिति की बेहतर समझ है। धन्यवाद।

— ब्रिगिड मैकडॉनेल

Answer 2

जाहिर है, sudoऐसे मामले में मेरे लिए पहली पसंद होगी। प्रमुख बिंदु दिखाई देता है होना करने के लिए है कि सबसे अधिक (वास्तविक) व्यवस्थापक वास्तव में उपयोग नहीं करते हैं /etc/sudoersइसकी पूरी संभव सीमा तक ( User_Alias, Runas_Alias, Host_Alias, Cmnd_Alias)।

अधिकांश प्रवेश केवल मौजूदा नियमों में से कुछ का उपयोग करके समाप्त होते हैं और उपयोगकर्ताओं को जोड़ते हैं, या इससे भी बदतर, केवल उन उपयोगकर्ताओं को sudoसमूह में जोड़ते हैं जिनके लिए एक नियम आमतौर पर उबंटू सेटअप ( %sudo...) पर मौजूद है । यह, निश्चित रूप से, संबंधित उपयोगकर्ताओं को मुफ्त शासन और सुपरयुसर खाते की पूरी शक्ति देता है।

आपकी टिप्पणी को देखते हुए:

इसलिए मैंने उन्हें जोड़ा /etc/sudoers

मुझे लगता है कि आप भी इसका उपयोग संभव हद तक नहीं करते हैं।

आपके जैसे परिदृश्य में मैं सचमुच उन कुछ क्रियाओं को लिपिबद्ध करूँगा जिनके लिए बॉब को सीमित किया जाना है। वास्तव में यह मैंने एक सर्वर पर किया है जिसे मैं बनाए रखता हूं, दो विशेष उपयोगकर्ताओं को एक होस्ट पर एक विशेष KVM अतिथि को रिबूट करने की अनुमति देता है। लिपियों में दुभाषिया के लिए पूर्ण पथ के साथ एक हैशबैंग होगा (उदाहरण के #!/bin/dashबजाय #!/usr/bin/env bash) और शायद एक शेल के साथ चलेगा जो विशेषाधिकार प्राप्त कार्यों ( /bin/dashया /bin/sh) के लिए कहीं और उपयोग किया जाता है । वो सिर्फ सावधानियां हैं। इसके अलावा, मैं बायनेरिज़ के सभी निरपेक्ष रास्तों को हार्डकोड करना और उनमें से कुछ का यथासंभव उपयोग करना सुनिश्चित करूँगा। उदाहरण के लिए, जब मैं bash/ s का उपयोग dashकरना पसंद करूंगा (देखें )। आप किसी चर को पूर्ण पथ निर्दिष्ट करके और उस चर के आधार पर कार्यक्रम का उल्लेख करके इसे बनाए रख सकते हैं (builtincommandman bash$VIRSHके बजाय /usr/bin/virsh)। यदि आप कर सकते हैं, तो उन्हें कॉल करने से पहले किसी भी बाहरी स्क्रिप्ट के कोड को पशु चिकित्सक करें। खासकर यदि आपको उन्हें विशेषाधिकार प्राप्त संदर्भ में कॉल करने की आवश्यकता है। मेरे मामले में मैं उपयोगकर्ताओं को एक विशेष रूट डायरेक्टरी और एक विशेष एसएसएच सबसिस्टम तक भी सीमित करता हूं क्योंकि वे केवल मशीन के माध्यम से sshdऔर सार्वजनिक प्रमाणीकरण से जुड़ते हैं । जाहिर है आपको इसकी आवश्यकता नहीं है।

chown root: <the-script>; chmod u=rw,a=,a+rx <the-script>किसी को रोकने के लिए सुनिश्चित करें लेकिन rootइसके साथ छेड़छाड़ से उचित है। लक्ष्य बायनेरिज़ पर सक्षम बिट्स setuidऔर setgidबिट्स के साथ सावधान रहें ( findउन्हें स्पॉट करने के लिए इस्तेमाल किया जा सकता है)। आइए उस पल के लिए मान लें, जिसमें आपकी स्क्रिप्ट रहती है /usr/sbin/priv-action।

अब अपने को संपादित करें /etc/sudoers। noexecअन्य बायनेरिज़ को रोकने के लिए उपयोग किया जा सकता है जो स्पष्ट रूप से अनुमत है। वास्तव में बहुत सारी अतिरिक्त सेटिंग्स हैं, न कि केवल उन पर जो मैं यहां बता रहा हूं। इसलिए सलाह अवश्य लें man sudoers।

अब मैं User_Aliasअपनी sudoersफ़ाइल में उपयोगकर्ताओं ( ) का नाम देना पसंद करता हूं , लेकिन आप बस एक Group_Alias( man sudoers) या एक वास्तविक सिस्टम समूह (जैसे:) का उपयोग कर सकते हैं %sudo:

# The list is comma-separated: bob,alice,...
User_Alias      LIMITED_ADMINS=bob

और फिर उस विशेष स्क्रिप्ट को निष्पादित करने की अनुमति देने के लिए एक कमांड उपनाम जोड़ें:

# The list is comma-separated: /usr/sbin/priv-action,/bin/bash,...
Cmnd_Alias      PRIV_ACTION=/usr/sbin/priv-action

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

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

पिछली उर्फ ​​परिभाषाओं के विपरीत, लाइन के लिए स्पष्टीकरण की आवश्यकता होती है। तो चलिए पहले "उपयोगकर्ता विनिर्देश" लाइन माध्य पर भागों में खुदाई करते हैं। यहाँ man sudoersमदद करता है:

एक उपयोगकर्ता विनिर्देश की मूल संरचना है who where = (as_whom) what।

उदाहरण पंक्ति (अधिकांश Ubuntu सेटअपों पर पाई गई):

root    ALL=(ALL) ALL

यह कहता है कि एक उपयोगकर्ता नाम root ( #0इसे यूआईडी को टाई करने के लिए 0), सभी मेजबानों पर, किसी भी उपयोगकर्ता संदर्भ के तहत कुछ भी चला सकता है, लेकिन उसके पासवर्ड के लिए कहा जाएगा (डिफ़ॉल्ट व्यवहार मानकर)। NOPASSWDअंतिम से पहले टैग जोड़ना ALLतब भी rootपासवर्ड के बिना पूछे जाने की अनुमति होगी (जैसे:) root ALL=(ALL) NOPASSWD:ALL। ALLविभिन्न उपनामों के लिए एक आंतरिक वाइल्डकार्ड उपनाम है।

लेकिन वापस बॉब के लिए:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

उपयोगकर्ता को दिए गए आदेशों को चलाने के लिए उपयोगकर्ता (समूह के रूप में , सभी होस्ट्स पर, जो है, उसे चलाने के लिए) bobऔर अन्य सूचीबद्ध सदस्यों को अनुमति देगा । सब ठीक हो जाएगा। फिर भी यह मानकर कि आप इस स्क्रिप्ट को लिखते हैं, आप विभिन्न मापदंडों की अनुमति दे सकते हैं, जिससे कई स्क्रिप्ट लिखने से बच सकते हैं। ख़ुशी से शेल-जैसे वाइल्डकार्ड को पारित करने की अनुमति दी गई तर्कों की संभावनाओं को सीमित करने के लिए लेता है।User_Alias LIMITED_ADMINSALLrootman sudoersCmnd_Alias PRIV_ACTION/etc/sudoers

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

आप सभी प्रकार के जटिल के साथ आ सकते हैं - जो आपके विशेष मामले के लिए सुरक्षा पहलू - समाधानों की वास्तव में मदद नहीं कर सकते हैं, लेकिन एक बार जब आप बोलते हैं तो आप की मूल शब्दावली /etc/sudoersकाफी जादू कर सकती है :)

NB: ध्यान रखें कि /etc/sudoers.d/यदि आप ऐसा महसूस करते हैं तो आप एक नई फ़ाइल भी बना सकते हैं । यह मानता है कि आपकी /etc/sudoersपंक्ति में यह है :

#includedir /etc/sudoers.d

Answer 3

यूनिक्स / लिनक्स में केवल एक सुपर उपयोगकर्ता है, इसका नाम रूट है, लेकिन sudoers उपयोगकर्ता हैं जो रूट बन सकते हैं। आपको समूहों का उपयोग करना चाहिए:

newgrp admins

और फिर उस समूह के उपयोगकर्ताओं को असाइन करें:

chgrp alice admins

उसके बाद sudoers कॉन्फिग फाइल में एडिम्स ग्रुप को जोड़ें जैसे कि ग्रुप यूजर था।

अपडेट करें

या आप किसी भी उपयोगकर्ता को व्यवस्थापक समूह में जोड़ सकते हैं:

chgrp alice admin

Comments

क्षमा करें, मैंने टैब कुंजी को हिट किया और इसे बिना खत्म किए भेज दिया।

— फ्रांसिस्को वाल्डेज़ 19

अधूरे उत्तर पर आधारित ज़ोर्क्ड टिप्पणी। वर्तमान उत्तर का प्रयास करना। यह मानते हुए कि भविष्य के पाठकों के लिए अतिरिक्त एक्सपोजर शायद sadadmin कोर के साथ कम परिचित है।

— ब्रिगिड मैकडॉनेल

बेशक मैं अहंकारी होने का मतलब नहीं था, वहाँ sysadmin के

— फ्रांसिस्को वाल्डेज़

मुझे पता है ServerFault मौजूद है। मैं यहां पूछ रहा हूं क्योंकि यह एक उबंटू-विशिष्ट व्यवहार है।

— ब्रिगिड मैकडोनेल

AFAIK: adduser <user>, addgroup <group>और adduser <user> <group>Debian / Ubuntu पर पसंदीदा तरीका है।

— 0xC0000022L