تقييد مشاركة 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 نفسه، ولهذا ينتمي القرار إلى تعريف المشاركة وتنتمي المراقبة إلى عملية الاستجابة. أبقِ الاثنين منفصلين، ويبقى التصميم صادقاً بشأن ما يفرضه.