הגבלת שיתוף 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, ולכן ההחלטה שייכת להגדרת השיתוף והניטור לתהליך התגובה. שמרו עליהם נפרדים והעיצוב יישאר כנה לגבי מה שהוא כופה.