लिनक्स पर डिफ़ॉल्ट समूहों और उपयोगकर्ताओं के पीछे कारण


15

कुछ सामान्य लिनक्स वितरण (क्रमशः ArchLinux और Debian) पर डिफ़ॉल्ट उपयोगकर्ताओं और समूहों के प्रबंधन पर एक नज़र रखने के बाद, मैं इसके बारे में दो बातें और डिफ़ॉल्ट सेटअप और कॉन्फ़िगरेशन को संशोधित करने के परिणामों के बारे में सोच रहा हूं।

के लिए डिफ़ॉल्ट मान USERGROUPS_ENABमें /etc/login.defsजो से परिलक्षित होता है होने के लिए "हाँ", लगता है "डिफ़ॉल्ट रूप से, एक समूह भी नए उपयोगकर्ता के लिए बनाया जाएगा" में पाया जा सकता है कि useradd, एक, आदमी तो हर बार एक नया उपयोगकर्ता बनाए समूह एक ही नाम और केवल इस नए उपयोगकर्ता के साथ बनाया गया है। क्या इसका कोई उपयोग है या यह सिर्फ एक प्लेसहोल्डर है?

मुझे ऐसा लग रहा है कि हम ऐसा करके उपयोगकर्ता / समूह / अन्य के रूप में अधिकार प्रबंधन का एक हिस्सा खो रहे हैं । क्या एक समूह "उपयोगकर्ता" या "नियमित" होना या जो भी आप इसे कॉल करना चाहते हैं वह खराब होगा, जो कि प्रत्येक उपयोगकर्ता के लिए डिफ़ॉल्ट समूह है, जिसके पास स्वयं का नहीं है?

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

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


यदि आप मुझे कुछ समय देंगे, तो मैं आपको एक अच्छा जवाब दूंगा। मैं सिर्फ एक धीमे टाइपर हूं। यह 30 मिनट या अधिक हो सकता है।
eyoung100

इन सभी समूहों का मुख्य बिंदु सेट-ग्रुप-आईडी कार्यक्रमों के लिए है।
बरमार

2
पहला सवाल इस एक के बहुत करीब है ।
लेजिया

@ मुख्यालय: निश्चित रूप से आपका समय लग सकता है, इसके लिए धन्यवाद!
हॉर्गिक्स

@Leiaz: मुझे एहसास हुआ कि लेकिन फिर भी यह पूछना चाहता था कि "क्या समूह" उपयोगकर्ताओं "या" नियमित "के लिए बुरा होगा या आप जो भी इसे कॉल करना चाहते हैं, वह प्रत्येक उपयोगकर्ता के लिए डिफ़ॉल्ट समूह है बजाय इसके कि उनका खुद का हो?" भाग, और एक परिचय के रूप में पहले क्या रखा गया था। मैंने मुख्य रूप से StackOverflow पर पोस्ट किया था लेकिन यहाँ निर्देशित किया गया था।
हॉर्गिक्स

जवाबों:


13

प्रति-उपयोगकर्ता समूह

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

जब USERGROUPS_ENABमें /etc/login.defs"नहीं", पर सेट किया जाता useraddसमूह में परिभाषित करने के लिए सभी बनाए गए उपभोक्ताओं कहते /etc/default/useraddद्वारा GROUPक्षेत्र। अधिकांश वितरण पर, यह GID पर सेट है100 पर जो आमतौर पर usersसमूह से मेल खाता है । यह आपको उपयोगकर्ताओं का अधिक सामान्य प्रबंधन करने की अनुमति देता है। फिर, यदि आपको बेहतर नियंत्रण की आवश्यकता है, तो आप इन समूहों को मैन्युअल रूप से जोड़ सकते हैं और उपयोगकर्ताओं को उनके साथ जोड़ सकते हैं जो समझ में आता है।

डिफ़ॉल्ट बनाए गए समूह

उनमें से ज्यादातर ऐतिहासिक कारणों से आए थे, लेकिन कई आज भी वैध उपयोग करते हैं:

  • डिस्क वह समूह है जो अधिकांश डिस्क ड्राइव उपकरणों का मालिक है
  • lp समानांतर पोर्ट का मालिक है (और कभी-कभी कप पर व्यवस्थापक अधिकारों के लिए कॉन्फ़िगर किया गया है)
  • Uucp अक्सर सीरियल पोर्ट (USB सीरियल पोर्ट सहित) का मालिक होता है
  • cdrom को cd ड्राइव पर बढ़ते विशेषाधिकारों के लिए आवश्यक है
  • कुछ सिस्टम sudo अधिकारों के लिए व्हील का उपयोग करते हैं; कुछ नहीं
  • आदि।

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


लिनक्स स्टैंडर्ड बेस कोर स्पेसिफिकेशन के अनुसार , केवल 3 उपयोगकर्ता जो रूट, बिन और डेमॉन हैं, बिल्कुल अनिवार्य हैं । अन्य समूहों के पीछे तर्क यह है:

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

इसलिए ऐसा लगता है कि इन समूहों को बनाए रखना बेहतर है। यह theorically , टूटना बिना उन्हें हटाने के लिए, हालांकि कुछ के लिए, "रहस्यमय" बातें नहीं सही काम करने के लिए शुरू हो सकता है संभव है (जैसे, कुछ आदमी पृष्ठों यदि आप उस समूह को मारने आदि से प्रस्तुत नहीं हो)। यह उन्हें वहां छोड़ने के लिए कोई नुकसान नहीं करता है, और आमतौर पर यह माना जाता है कि सभी लिनक्स सिस्टम उनके पास होंगे।


1
मैं अस्थायी फ़ाइलों को बनाने वाले आदमी के बारे में और कहां मिल सकता हूं? एक खुले हुए मैन पेज के साथ, ps aux | grep manमुझे मैन ग्रुप के तहत चलने वाली कोई भी प्रक्रिया नहीं दिखाई देती है, और find -group man /न ही मुझे कुछ भी दिखाता है। एक मानक आर्चलिनक्स इंस्टॉलेशन पर 2.6.7.1 आदमी के साथ प्रयास किया गया।
हॉर्गिक्स

6

प्रश्न 1: एक ही उपयोगकर्ता और समूह के लिए तर्क

हेलो, आई एम ईंसंग और यू होर्गिक्स। हम हर रोज काम पर जाते हैं और प्रोग्रामर के समान लिनक्स सर्वर में लॉगिन करते हैं। एक दिन पहले, लंबे समय से नहीं, हमारे सिस्टम व्यवस्थापक ने उपयोगकर्ता निर्माण और रखरखाव को खुद पर आसान बनाने का फैसला किया, इसलिए उन्होंने USERGROUPS_ENABविकल्प को बंद कर दिया और सभी मौजूदा उपयोगकर्ताओं को नए usersसमूह में डाल दिया ।


इसने उपयोगकर्ता निर्माण को आसान बना दिया लेकिन आपके द्वारा देखे गए रखरखाव को नहीं क्योंकि सभी उपयोगकर्ता अन्य सभी उपयोगकर्ता फ़ाइलों तक पहुँच सकते हैं। कॉरपोरेट सेटिंग में यह एक बड़ी संख्या है जो सर्बानस ऑक्सले और अलगाव के कर्तव्यों जैसी चीजों के कारण नहीं है । यदि मैं फ़ाइल A बनाता हूं, तो समूह बिट उपयोगकर्ता समूह पर सेट हो जाता है, जिसका अर्थ है कि सभी उपयोगकर्ता कम से कम फाइल ए पढ़ सकते हैं। यदि sys व्यवस्थापक आलसी है, तो कुछ मामलों में सभी उपयोगकर्ता RW फाइल को RW कर सकते हैं। यह सरबेंस ऑक्सले को हरा देता है। और SoD क्योंकि अलग-अलग विभागों को किसी अन्य व्यक्ति के दस्तावेज को बहुत कम लिखने में सक्षम नहीं होना चाहिए।


उपयोगकर्ता / समूह सक्षम होने के साथ अगर मैं एक दस्तावेज बनाता हूं तो वह केवल मेरे पास rwx अधिकार है। चूंकि मेरे समूह में कोई और नहीं है, जब वे मेरा दस्तावेज़ खोलते हैं तो उन्हें एक चेतावनी के साथ एक खाली पृष्ठ दिखाई देता है। यह सर्बनेस-ऑक्सले और SoD को लागू करता है। यदि मैं अन्य उपयोगकर्ताओं को आमंत्रित करता हूं, तो उन उपयोगकर्ताओं को rw एक्सेस की अनुमति है, और ऐसा करने से मुझे पता है कि जो वे देखते हैं वह मुझे या उन्हें काटने के लिए वापस नहीं आएगा। जैसा कि अन्य लोगों ने कहा है, अगर घर पर, तो वह अलगाव आपके लिए महत्वपूर्ण नहीं हो सकता है। यदि आप यह निर्धारित करते हैं, तो आप विकल्प को सुरक्षित रूप से बंद कर सकते हैं और सभी उपयोगकर्ताओं को users100 के GID के साथ एक समूह में जोड़ा जाएगा । नीचे 2 देखें।

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


प्रश्न 2: 500 के माध्यम से समूह आईडी 0

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

  • CUPS प्रिंटिंग सर्विस
  • MySQL सर्वर डेमॉन
  • एफ़टीपी सर्वर डेमॉन
  • एपेस वेब सर्वर
  • रिमोट कनेक्शन के लिए एक्स सर्वर सॉकेट
  • ALSA साउंड सिस्टम डेमॉन
  • DBUS सेवा

अन्य हैं, इसलिए यदि अन्य पाठक उपरोक्त सेवा सूची से जोड़ना या हटाना चाहते हैं, तो कृपया ऐसा करें।


5
अच्छा काल्पनिक, लेकिन एक असफल। 1. डिफ़ॉल्ट अनुमतियाँ आमतौर पर 022 नकाबपोश होती हैं, जिसका अर्थ है कि दूसरों ने वैसे भी पहुंच पढ़ ली है। 2. सीसैड केवल आलसी नहीं है, बल्कि अक्षम है, क्योंकि उसे विभाग के अनुसार समूह बनाने चाहिए थे और कुछ समूह को असाइन करने के बजाय, खाता निर्माण के दौरान सही समूह को सौंपा गया था। USERGROUPS_ENABतो बंद कर दिया रहना चाहिए। अक्षम करना USERGROUPS_ENAB! = सभी उपयोगकर्ताओं को एक ही समूह में रखना।
मुरु

पहले भाग के लिए @ECarterYound: मैं देख रहा हूं कि आप एक्सेस प्रोटेक्शन के बारे में क्या मतलब रखते हैं, और अगर मैं गलत हूं तो मुझे सही करें, लेकिन usersसमूह में सभी उपयोगकर्ता होने पर समूहों पर उचित अधिकार प्रबंधन के साथ समस्या नहीं होनी चाहिए, जो कड़ाई से समान नहीं दे रहा है मालिक की तुलना में समूह के अधिकार। तो USERGROUPS_ENABचालू होने का एकमात्र अच्छा बिंदु एक आसान रखरखाव होना है क्योंकि यह आपको फ़ाइलों और निर्देशिकाओं को बनाते समय डिफ़ॉल्ट अधिकार रखने की अनुमति देता है, जबकि अन्य उपयोगकर्ताओं के लिए अभी भी प्रतिबंधित है?
होर्गिक्स

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

4

यदि हम सभी एक डिफ़ॉल्ट समूह साझा करते हैं, जैसे पुराने दिनों में, तो हमें समूह को अवरुद्ध करने के लिए हमारे umask को 077 पर सेट करना होगा। यदि डिफ़ॉल्ट मुझ पर है, तो मैं umask को 027 पर सेट कर सकता हूं, अब अगर मैं एक साझा समूह में एक निर्देशिका या फ़ाइल सेट करता हूं, तो यह समूह पढ़ सकता है। मुझे मोड के साथ भी गड़बड़ नहीं करनी है।

यह सिर्फ एक उदाहरण है, लेकिन सामान्य तौर पर यह समूहों को निष्क्रिय करने का एक तरीका है, जब तक आपको उनकी आवश्यकता नहीं होती है, एक तरह से जिससे उन्हें चालू करना और प्रबंधित करना आसान हो जाता है।


2

प्रति-उपयोगकर्ता समूह आपको "अपने होम निर्देशिका में गोपनीयता" के साथ-साथ "साझा फ़ोल्डरों में आसान सहयोग" दोनों की सुविधा देता है। प्रति उपयोगकर्ता समूहों के बिना, आपके पास या तो हो सकते हैं लेकिन दोनों नहीं। विवरण का पालन करें:

यूनिक्स एक बहु-उपयोगकर्ता प्रणाली है, चाहे वह कंपनी फ़ाइल सर्वर हो या 2 उपयोगकर्ताओं के साथ पीसी। "आपके घर निर्देशिका में गोपनीयता" को कई तरीकों से महसूस किया जा सकता है:

"Umask 077" सेट करें ताकि फाइलें आपके लिए rw के साथ बनाई जाएं और दूसरों के लिए कोई अनुमति न हों। वैकल्पिक रूप से, 027 या 022 तो कुछ या सभी पढ़ सकते हैं लेकिन अपनी फाइलें नहीं लिखें। स्पष्ट नुकसान यह है कि आप एक साझा फ़ोल्डर में सहयोग नहीं कर सकते हैं क्योंकि दूसरे उन फ़ाइलों पर काम नहीं कर सकते हैं जो आप सख्त अनुमतियों के कारण बनाते हैं। आप ऐसी फ़ाइलों पर अनुमतियां बदल सकते हैं, लेकिन यह "बहुत अधिक काम" है और अक्सर भूल जाती है।

सहयोग करने के लिए, आपको "umask 7" जैसा कुछ चाहिए ताकि आप और आपके द्वारा बनाया गया समूह आपके द्वारा बनाई गई फ़ाइलों को पढ़ और लिख सकें। यह उन साझा किए गए फ़ोल्डरों और समूहों के लिए बहुत अच्छा है, जिनमें सभी लोगों की साझा पहुंच की आवश्यकता होती है। लेकिन आपने अपने होम फोल्डर में गोपनीयता ढीली कर दी है!

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

आप अभी भी साझा किए गए फ़ोल्डरों में सहयोग कर सकते हैं। साझा किए गए फ़ोल्डर में फ़ाइलों को स्वयं के समूह के लिए "rw" मिलता है, और sysadmin ने साझा फ़ोल्डर स्थापित किया है ताकि एक साझा समूह (जिसे सहयोगी कहा जाता है) वहां फ़ाइलों के लिए समूह का मालिक होगा। यह इस सहयोगी समूह को बनाकर किया जाता है, सभी सहयोगी उपयोगकर्ताओं के साथ सदस्य के रूप में। फिर, व्यवस्थापक साझा फ़ोल्डर के समूह के स्वामित्व को "सहयोगियों" पर सेट करता है और साझा फ़ोल्डर के लिए SETGID अनुमति सेट करता है। SETGID के साथ, साझा किए गए फ़ोल्डर में बनाई गई किसी भी चीज़ को साझा फ़ोल्डर के समान समूह स्वामी मिलेगा - अर्थात "सहयोगी" समूह। और umask 7 (या वैकल्पिक रूप से 2) के साथ, इस समूह के लोग सभी ने पढ़ा है + लिख सकते हैं और इसलिए सहयोग कर सकते हैं।


0

मूल रूप से, यूनिक्स प्रक्रियाएं एक समय में एक समूह से संबंधित हो सकती हैं (वहां एक chgrp(1)कमांड हुआ करती थी, जो वेस्टिअल पासवर्ड क्षेत्र में संग्रहीत समूह पासवर्ड के लिए पूछ रही थी /etc/groups)। प्लस सिस्टम का उपयोग उपयोगकर्ताओं के एक बारीकी से बुनना समूह द्वारा किया गया था। यह usersसमूह में हर किसी के लिए समझ में आता है , और समूह अनुमतियों द्वारा सामान-प्रणाली को साझा करता है। कोई वास्तविक सुरक्षा घबराहट, दर्जनों या इतने ही साथी उपयोगकर्ताओं की थोड़ी संदिग्धता। सब कुछ स्थानीय था, एक ही मशीन पर। कोई सामान साझा करने के लिए कोई नेटवर्क नहीं जैसे कि एक ब्लॉग या तो।

आज के यूनिक्स सिस्टम में सैकड़ों उपयोगकर्ता हैं, सुरक्षा आवश्यकताएं सख्त हैं, और उपयोगकर्ता (और प्रक्रियाएं) कई समूहों से संबंधित हो सकते हैं। प्रत्येक (अधिक क्लूलेस) उपयोगकर्ताओं को एक होम ग्रुप दें, और साझा करने के लिए इससे भटकने दें। या ACL का उपयोग करें।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.