एकाधिक * NIX पहचान यूआईडी के साथ खाते

Question

मैं उत्सुक हूं कि क्या कोई मानक अपेक्षित व्यवहार है और क्या लिनक्स / यूनिक्स पर एक से अधिक खाते बनाते समय इसे बुरा व्यवहार माना जाता है, जिसमें समान यूआईडी है। मैंने इसके साथ RHEL5 पर कुछ परीक्षण किया है और जैसा मैंने उम्मीद की थी, वैसा ही व्यवहार किया, लेकिन मुझे नहीं पता कि क्या मैं इस ट्रिक का उपयोग करके भाग्य को लुभा रहा हूं।

एक उदाहरण के रूप में, मान लें कि मेरे पास एक ही आईडी के साथ दो खाते हैं:

a1:$1$4zIl1:5000:5000::/home/a1:/bin/bash
a2:$1$bmh92:5000:5000::/home/a2:/bin/bash

इसका मतलब क्या है:

• मैं अपने स्वयं के पासवर्ड का उपयोग करके प्रत्येक खाते में लॉग इन कर सकता हूं।
• मेरे द्वारा बनाई गई फ़ाइलें समान UID होंगी।
• "Ls -l" जैसे उपकरण UID को फ़ाइल में पहली प्रविष्टि (इस मामले में a1) के रूप में सूचीबद्ध करेंगे।
• मैं दोनों खातों के बीच किसी भी अनुमति या स्वामित्व की समस्याओं से बचता हूं क्योंकि वे वास्तव में एक ही उपयोगकर्ता हैं।
• मुझे प्रत्येक खाते के लिए लॉगिन ऑडिटिंग मिल रही है, इसलिए मेरे पास सिस्टम में क्या हो रहा है, इसे ट्रैक करने में बेहतर ग्रैन्युलैरिटी है।

तो मेरे सवाल हैं:

• क्या यह क्षमता डिज़ाइन की गई है या यह काम करने के तरीके के अनुरूप है?
• क्या यह * निक्स वेरिएंट के अनुरूप है?
• क्या यह स्वीकृत अभ्यास है?
• क्या इस अभ्यास के अनपेक्षित परिणाम हैं?

ध्यान दें, यहाँ विचार यह है कि इसका उपयोग सिस्टम खातों के लिए किया जाए न कि सामान्य उपयोगकर्ता खातों के लिए।

Answer 1

मेरी राय:

क्या यह क्षमता डिज़ाइन की गई है या यह काम करने के तरीके के अनुरूप है?

इसे डिज़ाइन किया गया है। जब से मैंने * NIX का उपयोग करना शुरू किया है, आप उपयोगकर्ताओं को सामान्य समूहों में रखने में सक्षम हैं। यूआईडी के बिना समस्याओं के समान होने की क्षमता सिर्फ एक इच्छित परिणाम है, जो सब कुछ की तरह, गलत तरीके से प्रबंधित होने पर समस्याएं ला सकता है।

क्या यह * निक्स वेरिएंट के अनुरूप है?

मुझे ऐसा विश्वास है।

क्या यह स्वीकृत अभ्यास है?

आमतौर पर एक तरह से या किसी अन्य रूप में उपयोग किया जाता है, हाँ।

क्या इस अभ्यास के अनपेक्षित परिणाम हैं?

लॉगिन ऑडिटिंग के अलावा, आपके पास और कुछ नहीं है। जब तक आप ठीक वैसा नहीं चाहते थे, के साथ शुरू करने के लिए।

Comments

ध्यान दें, यह उपयोगकर्ताओं को एक ही समूह में नहीं रख रहा है, यह उन्हें समान समूह आईडी दे रहा है। तो GID 5000 के साथ एक समूह a1 होगा और GID 5000 के साथ समूह a2 होगा। यहाँ अधिक महत्वपूर्ण अवधारणा समान UID है, हालाँकि, जैसा कि आप प्रस्ताव करते हैं, आप समूह को संभाल सकते हैं।

— टिम

* NIX समूहों को दिया गया नाम अप्रासंगिक है। यह GID क्या मायने रखता है। एक से अधिक समूह को एक ही GID देकर आप कम पूरा कर रहे हैं; आप जितने चाहें उतने उपयोगकर्ताओं के लिए एक ही समूह के नाम / GID का उपयोग क्यों नहीं कर सकते? UID थोड़ा अलग मामला है, क्योंकि दोस्ताना नाम लॉग इन हो जाता है।

मुझे शायद यूआईडी पर चर्चा करने के साथ अटक जाना चाहिए था, क्योंकि यह प्रश्न में अधिक प्रासंगिक आइटम है।

— टिम

यह उत्तर आज मान्य नहीं है।

— अस्तारा

@ अस्त्र: विस्तृत करने के लिए देखभाल?

— user63623

Answer 2

क्या यह सभी यूनिक्स पर काम करेगा? हाँ।

क्या यह उपयोग करने के लिए एक अच्छी तकनीक है? नहीं। ऐसी अन्य तकनीकें हैं जो बेहतर हैं। उदाहरण के लिए, यूनिक्स समूहों का उचित उपयोग और कड़ाई से नियंत्रित "सुडो" विन्यास समान चीजें प्राप्त कर सकते हैं।

मैंने ठीक एक जगह देखी है जहाँ यह समस्याओं के बिना उपयोग किया गया था। FreeBSD में "toor" (रूट स्पेल्ड बैक) नामक एक दूसरा रूट अकाउंट बनाना पारंपरिक है जिसमें डिफ़ॉल्ट शेल के रूप में / बिन / श होता है। इस तरह अगर रूट का शेल गड़बड़ हो जाता है तो भी आप लॉग इन कर सकते हैं।

Comments

यह सिर्फ पारंपरिक नहीं है, यह डिफ़ॉल्ट है। टॉर उपयोगकर्ता को हर एक इंस्टाल पर बनाया जाता है, ताकि यदि उपयोगकर्ता रूट खाते को स्क्रू करे तो अभी भी उपलब्ध है। यह कहा जा रहा है, ज्यादातर लोग कभी भी टॉर यूजर अकाउंट के लिए पासवर्ड सेट नहीं करते हैं!

— X-Istence

यह उत्तर गलत है - तब और अब। मुझे यकीन है कि यह यूनिक्स के सभी वेरिएंट पर काम नहीं करेगा और नहीं करेगा ।

— अस्तारा

किस तरह से गलत है? कौन सा वेरिएंट काम नहीं करता है?

— टॉमऑनटाइम

फ़ाइल-आधारित नाम सेवा के नक्शे (/ etc / passwd, / etc / group) के साथ, यह मेरे द्वारा देखे गए प्रत्येक UNIX पर लगातार काम करता है। AIX या HP-UX (मैं भूल जाता हूं) कि स्वचालित रूप से एक ही GID के साथ "group2" (और "group3," आदि) नामक एक दूसरे समूह को जोड़ा जाएगा जब उस समूह के सदस्यों की संख्या फ़ाइल की तुलना में अधिक समय तक लाइन बनाने के लिए बढ़ी OS अधिकतम पंक्ति लंबाई। मैंने मैन्युअल रूप से दूसरे पर, और SunOS, और Linux पर किया। जब तक हम LDAP पर नहीं चले गए, तब तक। :)

— dannysauer

@TomOnTime यह इतना बुरा मामला नहीं है कि क्या बुरा व्यवहार निषिद्ध है, बल्कि विक्रेता द्वारा समर्थित और परीक्षण किए जाने के मामले में अधिक है । मैं किसी भी यूनिक्स या लिनक्स विक्रेता के बारे में नहीं जानता जो इस तरह के उपयोग का समर्थन करेगा। यह देखते हुए कि यह परीक्षण किए जाने की संभावना नहीं है, परिणाम अप्रयुक्त और अज्ञात हैं। सर्वोत्तम प्रथाओं का पालन करने वाली कोई भी कंपनी विक्रेता द्वारा समर्थित लोगों का पालन करेगी। ऐसा नहीं करने पर मुकदमों का दरवाजा खुल जाएगा। यह संभावित समस्याओं के लिए पूछ रहा है। ऐसी सुविधा का उपयोग करने के लिए, सभी आवश्यक पथों का पूर्ण परीक्षण करना होगा। यह बहुत महंगा होगा।

— एस्ट्रा

Answer 3

मैं आपके सवालों का एक कैनोनिकल जवाब नहीं दे सकता, लेकिन वास्तविक रूप से मेरी कंपनी रूट उपयोगकर्ता के साथ वर्षों से ऐसा कर रही है और इसके साथ कभी कोई समस्या नहीं हुई है। हम एक 'क्रोट' उपयोगकर्ता (यूआईडी 0) बनाते हैं, जिनके अस्तित्व का एकमात्र कारण / बिन / श या बिन / बैश के बजाय शेल के रूप में / बिन / क्ष है। मुझे पता है कि हमारे ओरेकल डीबीए अपने उपयोगकर्ताओं के साथ ऐसा ही कुछ करते हैं, प्रति उपयोगकर्ता 3 या 4 उपयोगकर्ता नाम हैं, सभी एक ही उपयोगकर्ता आईडी के साथ हैं (मेरा मानना ​​है कि यह प्रत्येक उपयोगकर्ता के साथ अलग-अलग घर निर्देशिकाएं करने के लिए किया गया था। हम कम से कम इसके लिए कर रहे हैं। दस साल, सोलारिस और लिनक्स पर। मुझे लगता है कि इसके डिजाइन के अनुसार काम करना।

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

Answer 4

क्या यह क्षमता डिज़ाइन की गई है या यह काम करने के तरीके के अनुरूप है?

इस तरह से डिज़ाइन किया गया।

क्या यह * निक्स वेरिएंट के अनुरूप है?

यह चाहिए, हाँ।

क्या यह स्वीकृत अभ्यास है?

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

क्या इस अभ्यास के अनपेक्षित परिणाम हैं?

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

क्या आप इसे पूरा करने की कोशिश कर रहे हैं जो इन दोनों उपयोगकर्ताओं को एक नए समूह में जोड़कर पूरा नहीं किया जाएगा और उस समूह को आपकी अनुमति की आवश्यकता है?

Answer 5

क्या इस अभ्यास के अनपेक्षित परिणाम हैं?

एक मुद्दा है जिससे मैं अवगत हूं। क्रोन इस यूआईडी अलियासिंग के साथ अच्छा नहीं खेलता है। क्रोन प्रविष्टियों को अपडेट करने के लिए पायथन स्क्रिप्ट से "crontab -i" चलाने का प्रयास करें। फिर उसी को संशोधित करने के लिए शेल में "crontab -e" चलाएं।

ध्यान दें कि अब cron (vixie, मुझे लगता है) ने a1 और a2 (in / var / spool / cron / a1 और / var / spool / cron / a2) दोनों के लिए समान प्रविष्टियों को अपडेट किया होगा।

Answer 6

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

यह निश्चित रूप से मानक नहीं है (मैंने इसे कहीं भी खेलने में नहीं देखा है), लेकिन ऐसा कोई कारण नहीं होना चाहिए कि आप इसे अपने स्वयं के वातावरण में उपयोग नहीं कर सकते यदि आप फिट देखते हैं।

अभी जो एकमात्र गेडा दिमाग में आता है, वह यह है कि यह ऑडिटिंग को मुश्किल बना सकता है। यदि आपके पास एक ही यूआईडी / gid के साथ दो उपयोगकर्ता हैं, तो मेरा मानना ​​है कि आपके पास एक कठिन समय होगा जो यह पता लगाएगा कि लॉग का विश्लेषण करते समय आपने क्या किया था।

Comments

यह सच है। प्रारंभिक लॉगिन a1 या a2 के रूप में / var / log / log / safe में रजिस्टर होता है, लेकिन बाद की गतिविधियाँ a1 के रूप में लॉग इन हो जाती हैं, कोई फर्क नहीं पड़ता कि आप कैसे लॉग इन करते हैं?

— Tim

Answer 7

प्राथमिक समूह आईडी साझा करना आम है, इसलिए यह प्रश्न वास्तव में यूआईडी के आसपास घूमता है ।

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

मुख्य बात मैं इस बारे में सतर्क रहूंगा कि किसी एक उपयोगकर्ता को हटाने जैसी चीजें हैं - कार्यक्रम भ्रमित हो सकता है और दोनों उपयोगकर्ताओं, या दोनों से संबंधित फ़ाइलों या समान चीजों को हटा सकता है ।

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

Comments

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

— टिम

Answer 8

BTW - यह सवाल / जवाब आज के ओएस के लिए अपडेट किया गया है।

Redhat से उद्धरण : अद्वितीय UID और GID नंबर असाइनमेंट का प्रबंधन , यह UID और GID के उपयोग और उनके प्रबंधन और कैसे जनरेटर (आईडी सर्वर) का वर्णन करता है

यादृच्छिक यूआईडी और जीआईडी ​​मान उत्पन्न करना चाहिए और साथ ही यह सुनिश्चित करना होगा कि प्रतिकृतियां कभी भी समान यूआईडी या जीआईडी ​​मूल्य उत्पन्न न करें। यदि किसी एकल संगठन में कई अलग-अलग डोमेन हैं, तो यूआईडी और जीआईडी ​​नंबर के लिए विशिष्ट आईडीआईडी ​​डोमेन को पार करने की आवश्यकता हो सकती है।

इसी तरह, उपयोगिताओं जो सिस्टम तक पहुंच की अनुमति देती हैं वे अप्रत्याशित रूप से व्यवहार कर सकते हैं (एक ही संदर्भ):

यदि दो प्रविष्टियों को एक ही आईडी नंबर दिया जाता है, तो उस नंबर की खोज में केवल पहली प्रविष्टि वापस आ जाती है।

समस्या तब आती है जब "पहले" की अवधारणा को परिभाषित किया गया है। स्थापित सेवा के आधार पर, उपयोगकर्ता नाम को एक चर आकार के हैश में रखा जा सकता है जो असंगत कारकों के आधार पर एक अलग उपयोगकर्ता नाम लौटाएगा। (मुझे पता है कि यह सच है, जैसा कि मैंने कभी-कभी 2 उपयोगकर्ता नाम w / एक आईडी का उपयोग करने की कोशिश की है, एक स्थानीय उपयोगकर्ता नाम है, और दूसरा एक domain.username है जिसे मैं UID में मैप करना चाहता था (जिसे मैंने अंततः संबोधित किया था) एक पूरी तरह से अलग), लेकिन मैं "usera" के साथ लॉग इन कर सकता हूं, एक "हू" या "id" कर सकता हूं और "userb" या "usera" देख सकता हूं - बेतरतीब ढंग से।

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

सूर्य (अब oracle) yp (येलोपेज) या NIS (NetworkInformationServices) में, विशिष्टता की आवश्यकताओं के कई संदर्भ भी हैं। विशेष कार्य और सर्वर कई सर्वरों और डोमेन में अद्वितीय ID को आवंटित करने के लिए सेटअप हैं (उदाहरण uid_allocd, gid_allocd है - UID और GID आवंटन दाता मेन्यू

एक तीसरा स्रोत जो जाँच सकता है वह है NFS खाता मानचित्रण के लिए Microsoft का सर्वर प्रलेखन। एनएफएस एक यूनिक्स फाइल शेयर प्रोटोकॉल है और वे वर्णन करते हैं कि आईडी द्वारा फ़ाइल अनुमतियों और पहुंच को कैसे बनाए रखा जाता है। वहाँ, वे लिखते हैं:

• यूआईडी। यह उपयोगकर्ताओं द्वारा पहचान करने के लिए UNIX ऑपरेटिंग सिस्टम द्वारा उपयोग किया गया एक अहस्ताक्षरित पूर्णांक है और पासवार्ड फ़ाइल में विशिष्ट होना चाहिए।

• GID। यह UNIX कर्नेल द्वारा समूहों की पहचान करने के लिए उपयोग किया गया एक अहस्ताक्षरित पूर्णांक है और समूह फ़ाइल में अद्वितीय होना चाहिए। MS-NFS- प्रबंधन पृष्ठ

हालांकि कुछ OS ने कई नामों / UID (BSD डेरिवेटिव्स, शायद?) की अनुमति दी हो सकती है, अधिकांश OS इस पर विशिष्ट होते हैं और अप्रत्याशित रूप से व्यवहार कर सकते हैं जब वे नहीं हैं।

नोट - मैं इस पृष्ठ को जोड़ रहा हूं, क्योंकि किसी ने इस दिनांकित प्रविष्टि को गैर-विशिष्ट यूआईडी / जीआईडी ​​के ... को समायोजित करने के लिए आधुनिक बर्तनों के समर्थन के रूप में संदर्भित किया है, जो कि ज्यादातर नहीं।

Answer 9

मैं यह भी नहीं जानता कि यह एक अच्छा विचार है या नहीं, लेकिन मैं उपरोक्त व्यवहार का उपयोग कुछ स्थानों पर करता हूं। अधिकतर यह उन खातों के लिए होता है, जहां ftp / sftp सर्वर तक पहुंचने और वेब साइट सामग्री को अपडेट करने के लिए उपयोग किया जाता है। यह कुछ भी तोड़ने के लिए नहीं लग रहा था और अनुमतियों से निपटने को आसान बनाने के लिए लग रहा था कि यह कई खातों के साथ होगा।

Answer 10

बस एक ही UID के साथ कई खातों के उपयोग से उपजी (बल्कि अस्पष्ट) समस्या में भाग गया, और सोचा कि मैं इसे एक उदाहरण के रूप में साझा करूंगा कि यह अच्छा अभ्यास क्यों नहीं है।

मेरे मामले में, एक विक्रेता ने एक Informix डेटाबेस सर्वर और RHEL 7 पर एक वेब एप्लिकेशन सर्वर स्थापित किया। सेटअप के दौरान, UID 0 के साथ कई "रूट" खाते बनाए गए (मुझसे ऐसा क्यों नहीं पूछें)। यानी, "रूट", "user1" और "user2", सभी में UID 0 है।

RHEL 7 सर्वर को बाद में winbind का उपयोग करके सक्रिय निर्देशिका डोमेन में शामिल किया गया था। इस बिंदु पर, Informix DB सर्वर अब शुरू नहीं कर सकता। oninitयह कहते हुए कि एक त्रुटि संदेश के साथ रनिंग विफल हो रही थी "Must be a DBSA to run this program"।

समस्या निवारण के दौरान हमने यह पाया:

1. सक्रिय निर्देशिका में रनिंग id rootया getent passwd 0(यूआईडी 0 को एक उपयोगकर्ता नाम में हल करने के लिए) सिस्टम में शामिल हो गया, "रूट" के बजाय बेतरतीब ढंग से या तो "user1" या "user2" लौटाएगा।

2. Informix स्पष्ट रूप से यह जांचने के लिए एक स्ट्रिंग की तुलना में निर्भर था कि क्या यह शुरू करने वाले उपयोगकर्ता का शाब्दिक उपयोगकर्ता नाम "रूट" था और अन्यथा विफल हो जाएगा।

3. Winbind के बिना, id rootऔर getent passwd 0उपयोगकर्ता नाम के रूप में लगातार "रूट" लौटाएगा।

फिक्स कैशिंग और दृढ़ता को अक्षम करना था /etc/nscd.conf:

enable-cache    passwd      no
persistent      passwd      no

इस परिवर्तन के बाद, UID 0 ने एक बार फिर से "रूट" का समाधान किया और Informix शुरू हो सकता है।

आशा है कि यह किसी के लिए उपयोगी होगा।

Comments

मुझे लगता है कि यह काम किया था और पूरी तरह से "वापस" पर तब भी नहीं गिरा था जब यूआईडी 16-बिट संख्या थी और बस एक मशीन में प्रवेश करने के तरीके के रूप में इस्तेमाल किया गया था। इसी तरह, मुझे लगता है कि यूयूआईडी और GUIDs की शुरुआत के साथ यह बदलना शुरू हो गया, 128 बिट्स / संख्या विशेष रूप से उस आकार में बनाई गई थी कि यह बहुत ही संभावना नहीं थी कि दो अलग-अलग उपयोगकर्ता एक ही आईडी के साथ समाप्त हो जाएंगे। यह ट्रैकिंग, बिलिंग + लाइसेंसिंग के लिए था। जैसे-जैसे सरकारें तकनीक पर नियंत्रण बढ़ाती हैं, वैसे-वैसे यूनिक आईडी की आवश्यकताएं बढ़ती गई हैं। गुमनामी को दूर करने की जरूरत है। नहीं, मैं पागल नहीं हूँ, सच में! ; ^ /

— अस्तारा