Samba शेयर को एक उपयोगकर्ता और एक VPN पते तक सीमित करें

इस डिज़ाइन में दो अलग-अलग अनुमतियाँ उलझ जाती हैं: कौन निर्देशिका का उपयोग कर सकता है, और कौन-से पते जुड़ ही सकते हैं। स्रोत सूची के बगल में खाता सूची लिखना जोड़ी जैसा लगता है, पर Samba दोनों सूचियों को स्वतंत्र शर्तों के रूप में आँकता है। जो दोनों पूरी करता है उसे प्रवेश मिलता है, और यह उस नियम से व्यापक है जो अधिकांश प्रशासक चाहते हैं। समाधान या तो शेयर का अलग विन्यास है या ऐसी नीति परत जो जोड़ी व्यक्त कर सके।

भ्रम: दो सूचियाँ एक नियम बनाती हैं

smb.conf संदर्भ valid users और hosts allow को दो असंबंधित पैरामीटर के रूप में परिभाषित करता है, और एक ही शेयर पर दोनों सेट करने से भ्रम शुरू होता है। valid users = mira, tomas और hosts allow = 10.77.0.21, 10.77.0.22 सेट करें और चार संयोजन स्वीकार होते हैं: मीरा किसी भी पते से, टॉमस किसी भी पते से। विन्यास में कुछ भी पहले नाम को पहले पते से नहीं बाँधता, और नाम जिस क्रम में आते हैं उसका कोई अर्थ नहीं है। उन्हें फिर से क्रम में लगाना, दूसरी hosts allow पंक्ति जोड़ना या हर पंक्ति में एक नाम रखना कुछ नहीं बदलता। परिणाम दो सूचियों का गुणनफल है, उनके बीच कोई मैपिंग नहीं।

अधिकांश लोग वास्तव में जो चाहते हैं वह संकीर्ण है: मीरा केवल एक पते से, टॉमस केवल दूसरे से। एक शेयर परिभाषा के पास उस बंधन का कोई सिंटैक्स नहीं है, और कोई भी चतुर क्रम उसे नहीं बनाता। यह नीति का ऐसा स्वरूप है जिसे Samba एक शेयर के भीतर व्यक्त नहीं करता, और वहीं यह भ्रम जीवित रहता है।

Samba क्या और किस क्रम में आँकता है

चरण एक निश्चित क्रम में चलते हैं, और क्रम गलत होने पर गलत निदान मिलता है। क्लाइंट कनेक्शन खोलता है; वैश्विक होस्ट जाँच चलती है यदि वह कॉन्फ़िगर हो; सत्र सेटअप खाते को प्रमाणित करता है; फिर क्लाइंट शेयर से जुड़ता है, जहाँ उस शेयर की अपनी होस्ट सूची, valid users और केवल-पढ़ने सेटिंग लागू होती है; और फ़ाइल खुलने पर ही प्रमाणित पहचान की फ़ाइलसिस्टम अनुमतियाँ निर्णय लेती हैं। प्रत्येक चरण अकेले अनुरोध अस्वीकार कर सकता है, और एक से गुजरना अगले के बारे में कुछ नहीं कहता। महत्वपूर्ण परिणाम यह है कि शेयर की होस्ट सूची आँकने तक खाता ज्ञात होता है, और होस्ट सूची के पास अभी भी उस खाते का नाम लेने का कोई तरीका नहीं है।

इसी कारण एक शेयर एक उपयोगकर्ता को एक पते से नहीं बाँध सकता: hosts allow और valid users अलग शर्तें हैं जो एक ही ट्री-कनेक्शन चरण में लागू होती हैं, और हर एक अपने प्रश्न का उत्तर देती है। होस्ट शर्त खाते का नाम कभी इनपुट के रूप में नहीं लेती, इसलिए इसे प्रति उपयोगकर्ता नहीं लिखा जा सकता। जोड़ी केवल दूसरा शेयर या Samba के बाहर की नीति परत व्यक्त कर सकती है।

वैश्विक मान इसलिए महत्वपूर्ण हैं कि वे कैसे विरासत में मिलते हैं। जो शेयर hosts allow छोड़ देता है वह वैश्विक मान विरासत में लेता है, और जो शेयर अपना सेट करता है वह उस मान को वैश्विक के स्थान पर उपयोग करता है, उसके अतिरिक्त नहीं। इसलिए चौड़ी वैश्विक सूची उन शेयरों को चौड़ा करती है जो पैरामीटर कभी सेट नहीं करते, और जो शेयर अपना निर्धारित करता है उस पर कुछ नहीं करती। testparm -s चलाएँ और वह जो प्रति-शेयर मान छापता है उन्हें पढ़ें, क्योंकि वही आउटपुट प्रभावी नीति है, डिस्क पर रखी फ़ाइल नहीं।

एक शेयर को सीमित करना भी बाकी सर्वर के लिए कुछ नहीं करता। अन्य शेयर, प्रिंटर कतारें और IPC कनेक्शन अपने नियम रखते हैं, इसलिए एक शेयर की पता सूची पर निर्भर डिज़ाइन होस्ट नहीं, एक मार्ग की रक्षा करता है।

एक निर्देशिका पर दो शेयर नाम

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

[shared-mira]
    path = /srv/shared
    guest ok = no
    read only = yes
    valid users = mira
    hosts allow = 10.77.0.21
    hosts deny = ALL

[shared-tomas]
    path = /srv/shared
    guest ok = no
    read only = yes
    valid users = tomas
    hosts allow = 10.77.0.22
    hosts deny = ALL

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

दोनों ब्लॉक एक ही मार्ग की ओर इशारा करते हैं, इसलिए निर्देशिका में बदलाव दोनों शेयरों को प्रभावित करता है। सामान्यतः यही उद्देश्य है, पर इसका अर्थ यह भी है कि अनुमति की गलती दोनों उपयोगकर्ताओं को एक साथ दिखती है।

स्रोत पता क्या सिद्ध कर सकता है

Samba जो पता देखता है वह वही पता है जो सर्वर तक पहुँचा, न कि वह जो क्लाइंट मानता है कि उसके पास है। जो VPN गेटवे हर क्लाइंट को एक ही स्रोत पते में अनुवादित करता है वह अंतर मिटा देता है: सभी क्लाइंट एक ही होस्ट के रूप में आते हैं और स्रोत सूची अब उन्हें अलग नहीं कर सकती। प्रति-क्लाइंट स्थिर आवंटन और स्रोत को सुरक्षित रखने वाला गेटवे पतों को नीति के रूप में उपयोग करने की पूर्वशर्तें हैं। दोनों के बिना सीमा उपयोगकर्ता नहीं, गेटवे को मापती है।

फिर भी, पता कोई उपकरण नहीं है। एक टनल पते के पीछे दो लैपटॉप, फिर से आवंटित लीज़ और साझा वर्कस्टेशन सभी इस मान्यता का खंडन करते हैं कि स्रोत किसी व्यक्ति की पहचान करता है। सीमा को नेटवर्क विस्तार मानें और प्रमाणित SMB खातों को पहचान परत के रूप में रखें, उपकरण प्राधिकरण चाहिए तो प्रमाणपत्र जैसे उपकरण क्रेडेंशियल के साथ।

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

क्रॉस किए गए जोड़ों से सिद्ध करें

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

testparm -s
smbclient //fileserver/shared-mira -U mira -c 'ls'
smbclient //fileserver/shared-tomas -U tomas -c 'ls'
smbstatus --shares

सिंटैक्स जाँच केवल यह सिद्ध करती है कि फ़ाइल पार्स होती है। क्रेडेंशियल, ACL और होस्ट निर्णय वास्तविक कनेक्शन से लागू होते हैं, इसलिए क्लाइंट कमांड उसी पते से चलाएँ जिसे जाँचना है और देखें कौन-सा चरण उसे अस्वीकार करता है। क्रॉस जोड़ी सफल हो तो प्रभावी होस्ट सूची ब्लॉक के संकेत से चौड़ी है, और testparm -s पहली चीज़ है जो पढ़नी चाहिए। क्रॉस जोड़ी गलत कारण से विफल हो तो संदिग्ध खाता या ACL है।

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