मैं उपयोगकर्ताओं को एक ही यूआईडी के साथ क्यों बना सकता हूं?

Question

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

दो उपयोगकर्ताओं के पास एक ही यूआईडी कैसे हो सकती है, क्या यह मेरे सिस्टम और पैकेज के लिए संघर्ष नहीं है?

root@kdc:~# id test12
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~# id test13
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~#

मैंने एक ही UID और GID के साथ दो उपयोगकर्ता जोड़े हैं: test12और test13

के उत्पादन /etc/passwd:

client@kdc:~$ cat /etc/passwd | grep test12
test12:x:1005:1000::/home/test12:/bin/sh
client@kdc:~$ cat /etc/passwd | grep test13
test13:x:1005:1000::/home/test13:/bin/sh

मैंने उपयोगकर्ताओं को जोड़ा useradd -ou 1005 -g1000 username.

मैं भ्रमित हो गया कि इसका उद्देश्य क्या है, और क्या यह अनुमतियों और उपयोगकर्ता लॉग आदि को प्रभावित कर सकता है इसलिए अब यदि किसी उपयोगकर्ता के साथ जोड़ा जाता है uid=0और gid=0रूट खाते की तरह विशेषाधिकार होंगे?

Comments

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

— पशुधर्मी

जैसे कि यह कह रहा है कि एक उपयोगकर्ता है जिसके पास यह आईडी है

— 15:27

ठीक है, मैंने प्रश्न को गलत समझा। मुझे लगा कि आपने उपयोगकर्ताओं को सामान्य रूप से बनाया है और सिस्टम ने उन्हें समान यूआईडी सौंपा है।

— पशुपतिसेकिया

कोई आदमी आम तौर पर नहीं, यहाँ सवाल, कैसे प्रणाली अद्वितीय uids स्वीकार करते हैं

— nux

समझ गया। अच्छा सवाल तो, स्पष्टीकरण के लिए धन्यवाद :)

— animaletdesequia

Answer 1

यहां जवाब यह है कि लिनक्स आपको खुद से बचाता नहीं है।

यदि आप वास्तव su rootमें / / आदि फाइलों में जाना चाहते हैं और सभी उपयोगकर्ताओं को समान यूआईडी देते हैं, तो आप कर सकते हैं। यह सिर्फ एक पाठ फ़ाइल है।

लेकिन आपको वास्तव में नहीं करना चाहिए और इसके अनपेक्षित परिणाम होंगे।

Comments

मेरा सवाल यह है कि प्रणाली इसे क्यों स्वीकार करती है?

— नक्स

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

— डिजिटल क्रिस

ठीक है, और useradd -oआप का उपयोग करके यह पहचानते हैं कि आप आदर्श से बाहर हैं adduser। जैसा कि @psusi ने उल्लेख किया है, यह एक ही आईडी की ओर इशारा करते हुए दो लॉगइन बनाता है जहाँ तक फ़ाइल अनुमतियाँ आदि हैं। यह संभवतः समस्याएँ भी पैदा करता है क्योंकि यह एक सामान्य उपयोग का मामला नहीं है और बहुत सारे पैकेजों के साथ कोई संदेह नहीं है।

— डिजिटल क्रिस

उत्तर: 2 लॉगइन्स समान फाइलसिस्टम अनुमतियों की ओर इशारा करते हैं।

— डिजिटल क्रिस

@ जोश में यह है, एक ही यूआईडी वाले कई उपयोगकर्ताओं के लिए वैध कारण हैं, एक उदाहरण के लिए मेरा जवाब देखें।

— terdon

Answer 2

इसके लिए वास्तव में वैध कारण हैं। उदाहरण के लिए, मैं एक प्रयोगशाला में काम करता था, जहाँ हम प्रत्येक के पास अपना कंप्यूटर $HOMEथा, लेकिन हमारा सर्वर द्वारा निर्यात की गई साझा ड्राइव में था। तो, मेरा $HOMEथा

/users/terdon

चूंकि /usersफ़ोल्डर वास्तव में मेरे स्थानीय मशीन पर नहीं था, लेकिन एनएफएस पर निर्यात किया गया था, जो किसी भी विश्लेषण के लिए I / O पर भारी था, मैं अपने स्थानीय हार्ड ड्राइव पर संग्रहीत डेटा का उपयोग करूंगा ताकि लैब के नेटवर्क को बोझ न डालें। उस अंत तक I, और बाकी सभी के पास दो उपयोगकर्ता थे: एक जो सिस्टम-वाइड था और एक वह जो मशीन में स्थानीय था। स्थानीय उपयोगकर्ता का घर था

/home/localuser

हालाँकि, मुझे अपनी फ़ाइलों तक पूर्ण पहुँच की आवश्यकता थी, चाहे मैं उस रूप में terdonया localuserजिस रूप में हमारे sysadmin ने लागू किया था, वह दोनों localuserऔर terdonएक ही UID को लागू करने के लिए था । इस तरह, मैं स्वतंत्र रूप से अपनी स्थानीय फाइलों में फेरबदल कर सकता हूं, चाहे मैं वर्तमान में किस उपयोगकर्ता के रूप में लॉग इन किया गया हो।

Comments

इस उत्तर के समर्थन में, यह ध्यान देने योग्य है कि कुछ सेटअप जैसे कि वर्चुअल ईमेल होस्टिंग इसका बहुत प्रभाव डालती है, यानी एक ही यूआईडी को साझा करने वाले वर्चुअल ईमेल खातों की एक बड़ी संख्या - डोवकोट मेल सर्वर के लिए प्रलेखन वास्तव में एक वैकल्पिक दृष्टिकोण के रूप में यह सुझाव देता है at wiki2.dovecot.org/UserIds#mailusers

— मैट थॉमसन

chmod 666एक ही प्रभाव नहीं होगा ?

— ब्रायन

@GIJoe जो दोनों उपयोगकर्ताओं को पढ़ने / लिखने की अनुमति देगा, लेकिन यह स्वामित्व को संरक्षित नहीं करेगा जो एक समस्या हो सकती है। साथ ही, सभी फ़ाइलों को उन अनुमतियों (उदाहरण के लिए ssh कुंजियों) पर सेट नहीं किया जा सकता है और हर समय अनुमतियों के साथ खेलना आवश्यक नहीं है।

— terdon

Answer 3

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

Comments

फिर सिस्टम उपयोगकर्ताओं के साथ कैसे व्यवहार करता है? साझा करने की अनुमति

— 15:27 पर

@nux, वे दोनों एक ही उपयोगकर्ता हैं। लॉग-इन करने के उद्देश्य से उनके पास एक अलग उपयोगकर्ता नाम / पासवर्ड हो सकता है।

— Psusi

@ bigbadonk420, शब्द "समर्थित" बल्कि अस्पष्ट है। यह निश्चित रूप से एक ऐसी चीज है जिसे आप हमेशा यूनिक्स सिस्टम पर कर सकते हैं और यह किसी अन्य उपयोगकर्ता को सेट करने के लिए काफी सामान्य बैकडोर हुआ करता था जिसका यूआईडी 0 है, ताकि आप पासवर्ड पता करने या बदलने की आवश्यकता के बिना लॉग इन कर सकें और प्रभावी रूप से रूट हो सकें। सामान्य रूट उपयोगकर्ता पर।

— Psusi

@ bigbadonk420 यह समर्थित है, ऐसे मामले हैं जहां यह उपयोगी है, एक उदाहरण के लिए मेरा जवाब देखें।

— terdon

Answer 4

यह वास्तव में एक ही आईडी वाले दो उपयोगकर्ताओं के लिए काफी सामान्य है। फ्रीबीएसडी पर, आमतौर पर यूआईडी 0 के साथ दो उपयोगकर्ता हैं: रूट और टॉर। रूट बिल्ट-इन / बिन / श शेल का उपयोग करता है, और टॉर एक अलग शेल का उपयोग करता है, आमतौर पर बैश।

Answer 5

यूनिक्स सिस्टम और लिनक्स आमतौर पर /etc/passwdफ़ाइल में डुप्लिकेट को प्रतिबंधित करने के लिए कुछ भी नहीं करते हैं। इस फ़ाइल का आशय यूआईडी को एक भौतिक नाम के साथ जोड़ना है जो कमांड लाइन टूल द्वारा प्रदर्शित किया जा सकता है जैसे कि lsउपयोगकर्ता फ़ाइलों को सूचीबद्ध कर रहे हैं।

$ ls -n | head -5
total 986000
drwxrwxr-x.   3 1000 1000      4096 Feb 13 19:51 1_archive_sansa
-rw-rw-r--.   1 1000 1000    760868 Dec 16 08:21 2.18.x Database Scheme.jpg
-rw-rw-r--.   1 1000 1000       972 Oct  6 20:26 abcdefg
drwxrwxr-x.   2 1000 1000      4096 Feb 11 03:34 advanced_linux_programming

इस फ़ाइल का अन्य इच्छित उद्देश्य यह निर्दिष्ट करना है कि लॉगिन करते समय उपयोगकर्ता को क्या शेल मिलेगा।

$ getent passwd saml
saml:x:1000:1000:saml:/home/saml:/bin/bash

यूनिक्स प्रकार के सिस्टम पर एक आम हमला वेक्टर एक सिस्टम /etc/passwdफाइल में इन जैसे लाइनों को जोड़ने के लिए है :

$ getent passwd r00t
r00t:x:0:0:root:/root:/bin/bash

$ getent passwd toor
toor:x:0:0:root:/root:/bin/bash

/etc/passwdफ़ाइल की भूमिका केवल उपयोगकर्ता खातों को ट्रैक करने के लिए नहीं है । उपयोगकर्ता नाम और पासवर्ड ट्रैक करने की भूमिका /etc/shadowफ़ाइल की जिम्मेदारी है । जब आपके सिस्टम डिस्क्स से फ़ाइलों को सूचीबद्ध कर रहा हो, तो ऐसी फाइलें /etc/passwdऔर /etc/groupवास्तव में एक मानव पठनीय नाम प्रदान करने के लिए होती हैं।

याद रखें कि आपकी फ़ाइलें UID / GID के वास्तविक नामों का उपयोग करके डिस्क पर लिखी गई हैं।

$ stat afile 
  File: ‘afile’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fd02h/64770d    Inode: 6560621     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/    saml)   Gid: ( 1000/    saml)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2014-02-27 15:54:21.852697029 -0500
Modify: 2014-02-27 15:54:21.852697029 -0500
Change: 2014-02-27 15:54:21.852697029 -0500
 Birth: -

सूचना Uid:और Gid:, संख्याएँ वास्तव में डिस्क पर क्या लिखी जाती हैं!

Answer 6

लिनक्स में, सभी उपयोगकर्ता और समूह वास्तव में केवल संख्याएँ हैं। idआपके द्वारा पोस्ट की गई कमांड का आउटपुट दिखाता है।

/etc/passwdफ़ाइल उपयोगकर्ता नक्शे नाम उपयोगकर्ता के लिए आईडी (संख्या) और उदाहरण उपलब्ध कराने की है में, आप बस एक ही उपयोगकर्ता ID के लिए दो उपयोगकर्ता नाम मैप किया गया है।

प्रभावी रूप से, आपने एक उपयोगकर्ता test12, आईडी 1005 बनाया है, जिसके पास दूसरा उपयोगकर्ता नाम भी है test13। हालाँकि यह सिस्टम यूआईडी 1005 को पहले उपयोगकर्ता नाम से पता चलता है, जो होगाtest12

लिनक्स "आपको" ऐसा करने देता है क्योंकि आपको ऐसा करने से रोकने के लिए कोई सिस्टम नहीं है। /etc/passwdकेवल एक पाठ फ़ाइल है, उपयोगकर्ता नाम उस फ़ाइल में उनके प्रवेश के लिए पाए गए यूआईडी के लिए मैप किए जाते हैं, यूआईडी को उस फ़ाइल में पहले उपयोगकर्ता नाम के लिए मैप किया जाता है।

लेकिन आपने जो बनाया है वह अन्य सिस्टम्स प्रशासकों के लिए एक भ्रामक स्थिति है; के यूआईडी को बदलकर इससे बचेंtest13

Comments

यह मेरा टेस्ट वर्चुअल मशीन मैन है, मेरा सवाल यह है कि एक ही uid के लिए दो उपयोगकर्ताओं को मैप करने के लिए एक उद्देश्य है

— nux

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

— जोश

यही कारण है कि मैंने इस सवाल को पूछा, जिसे मुझे जानना चाहिए, मुझे लगा कि यह एक भ्रमित करने वाला तरीका है

— nux

यह उलझनभरा है; इसलिए आपको ऐसा नहीं करना चाहिए। इसका "उद्देश्य" नहीं है, यह /etc/passwdफ़ाइल का अधिक दुरुपयोग है । लेकिन आपको ऐसा करने से रोकने के लिए कोई साधन नहीं है । क्या इसका कोई मतलब है?

— जोश

एक उपयोगकर्ता ने उल्लेख किया है कि लक्ष्य के लिए 2 लॉगिन बिंदु समान फाइल सिस्टम अनुमतियों के लिए हैं।

— नक्स

Answer 7

इसका कारण यह है कि आज इसकी अनुमति है, क्योंकि सिस्टम इसे रोकता नहीं है।

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

मूल रूप से केवल पासवार्ड और समूह फाइलें थीं, और उन्होंने अपना उद्देश्य पूरा किया। कोई नहीं था adduser कमांड नहीं, addgroup , फ़ाइलें vi या एड का उपयोग कर जड़ से संपादित किया गया।

कुछ झगड़े थे!

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

ज्ञात दोष थे। मुख्य बात यह है कि इसे दुनिया के लिए पठनीय होना चाहिए, ताकि उपयोगिताओं lsको मैप किया जा सके user-id => name। इसका मतलब था कि कोई भी सभी के एन्क्रिप्टेड पासवर्ड और सिस्टम के सभी उपयोगकर्ताओं और आईडी को देख सकता है।

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

shadowपासवर्ड फ़ाइल का आविष्कार होने से पहले, इसमें कुछ साल लग गए, इसने एन्क्रिप्टेड पासवर्ड छिपाकर थोड़ी अधिक सुरक्षा प्रदान की। फिर से, बस पर्याप्त जटिलता को जोड़ा गया था, लेकिन यह अभी भी काफी कच्चा और सरल था। उपयोगिताओं useraddऔर groupaddशुरू की गईं, जिन्हें रखा गया shadowऔर shadow-अद्यतन किया गया। के साथ शुरू करने के लिए, ये अक्सर विक्रेताओं के मालिकाना ऐडसर / ऐडग्रुप उपयोगिताओं के आसपास सरल शेल स्क्रिप्ट रैपर थे । फिर बस चलता ही रह गया।

कंप्यूटर के नेटवर्क बड़े हो रहे थे, लोग नौकरी पाने के लिए एक समय में कई काम कर रहे थे, इसलिए passwd/groupफाइलों का प्रशासन एक बुरा सपना बन रहा था, खासकर एनएफएस के साथ, इसलिए येलो पेज को एनआईएस के रूप में भी जाना जाता है ताकि बोझ को कम किया जा सके।

यह अब तक स्पष्ट हो रहा था कि कुछ और अधिक लचीली की आवश्यकता थी, और पीएएम का आविष्कार किया गया था। इसलिए यदि आप वास्तव में परिष्कृत थे और एक केंद्रीकृत, सुरक्षित, अद्वितीय-आईडी'एड, सभी घंटियाँ और सीटी प्रमाणीकरण प्रणाली चाहते थे तो आप एक केंद्रीय सर्वर को प्रमाणित करने के लिए कहेंगे, शायद एक रेडियस सर्वर, एलडीएपी सर्वर या सक्रिय निर्देशिका।

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

यही कारण है कि मुझे नहीं लगता कि सरल पासवार्ड फ़ाइल कभी भी बदल जाएगी। इसका कोई मतलब नहीं है, और यह सिर्फ उन £ 30 रास्पबेरी पाई के साथ 2 के लिए बहुत अच्छा है शायद 3 उपयोगकर्ता के निगरानी तापमान, और ट्विटर फ़ीड। ठीक है, तुम सिर्फ तुम उन्हें अद्वितीय चाहते हैं, और वहाँ रैपिंग से उत्साही को रोकने के लिए कुछ भी नहीं है अगर आपके उपयोगकर्ता के पहचान-पत्र के साथ एक सा सावधान रहना होगा useradd एक स्क्रिप्ट में जो पहले चयन सेट एक के लिए एक डेटाबेस (फाइल) से अगले विशिष्ट आईडी अद्वितीय आईडी, यदि आप यही चाहते हैं। यह सब के बाद खुला स्रोत है।

Answer 8

/etc/passwdफ़ाइल सिर्फ वास्तविक उपयोगकर्ता ID के लिए प्रतीकात्मक उपयोगकर्ता नाम मैप करता है। यदि आप जानबूझकर दो प्रतीकात्मक नाम बनाते हैं जो एक उपयोगकर्ता के लिए मैप करता है तो यह आपको देगा।

इसका मतलब यह नहीं है कि यह वास्तव में एक अच्छा विचार है। कुछ लोगों को बहुत विशिष्ट उपयोग के मामले मिल सकते हैं जहां वे इस सुविधा का लाभ उठा सकते हैं, लेकिन सामान्य तौर पर आपको ऐसा नहीं करना चाहिए।

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

Comments

इसे बग के रूप में क्यों बताया गया?

— नक्स

Answer 9

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

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

Answer 10

मुझे कुछ प्रमाण मिले जो @ andbalbal's answer का समर्थन करते हैं।

से APUE , §8.15:

कोई भी प्रक्रिया इसकी वास्तविक और प्रभावी उपयोगकर्ता आईडी और समूह आईडी का पता लगा सकती है। कभी-कभी, हालांकि, हम उस उपयोगकर्ता के लॉगिन नाम का पता लगाना चाहते हैं जो कार्यक्रम चला रहा है। हम getpwuid( getuid()) कॉल कर सकते हैं , लेकिन क्या होगा यदि किसी एकल उपयोगकर्ता के पास एक ही उपयोगकर्ता आईडी के साथ कई लॉगिन नाम हों? ( प्रत्येक प्रविष्टि के लिए एक अलग लॉग इन करने के लिए एक व्यक्ति के पास एक ही यूजर आईडी के साथ पासवर्ड फ़ाइल में कई प्रविष्टियाँ हो सकती हैं ।) सिस्टम सामान्य रूप से हमारे द्वारा लॉग इन किए गए नाम पर नज़र रखता है (धारा 6.8), और getloginफ़ंक्शन एक तरीका प्रदान करता है। उस लॉगिन नाम को लाने के लिए।

....

लॉगिन नाम को देखते हुए, हम इसका उपयोग पासवर्ड फ़ाइल में उपयोगकर्ता को देखने के लिए कर सकते हैं - लॉगिन शेल को निर्धारित करने के लिए, उदाहरण के लिए- उपयोग करना getpwnam।

Btw, मैं जानना चाहूंगा कि क्या कोई लॉग इन करते समय दूसरे शेल पर जा सकता है या नहीं।