PrivateTmp: ההוק כתב את הקובץ, אז לאן הוא נעלם?

הוקים מדווחים על הצלחה, ואותו נתיב עדיין נראה ריק מתוך מעטפת. שתי הקביעות יכולות להיות נכונות בו-זמנית, כי שירות systemd עשוי לחיות במרחב שמות ההרכבה שלו עם ספרייה זמנית פרטית. לאחר שמבינים זאת, השאלה המעניינת היא אם הכתיבה הצליחה בכלל.

שתי ספריות זמניות, נתיב אחד

הגדרת הבידוד נותנת ליחידה תצוגה פרטית של הספריות הזמניות במקום להפוך אותן לקריאה בלבד. תהליכים מחוץ ליחידה לא יכולים לראות מה היא כותבת שם, וכל מה שהיא משאירה מאחור נזרק כשהיחידה נעצרת. לכן נתיב שההוק מדפיס ונתיב שנבדק מתוך מעטפת יכולים להתייחס לאובייקטים שונים עם אותו שם.

זוהי בעיית נראות, והיא נראית כמו בעיית אובדן נתונים. שום דבר לא נמחק, כי הקובץ פשוט נמצא במרחב שמות שהמעטפת אינה חברה בו. אותה פקודה מתנהגת אחרת כשהיא מופעלת בתוך היחידה, וזו התצפית שבדרך כלל מכריעה את הוויכוח. קרא את הגדרות היחידה לפני שתסיק משהו על הכתיבה.

הפרד בין בלתי נראה לבלתי ניתן לכתיבה

כתיבה מוצלחת ופתיחה שנכשלה מייצרות ראיות שונות, וההבחנה הזו קובעת את התיקון. אם ההוק אומר שהקובץ נוצר אבל קורא חיצוני לא מוצא אותו, יש לך שאלת מרחב שמות. אם ההוק מדווח על שגיאת הרשאה או פתיחה שנכשלה, הקובץ מעולם לא נכתב ושום שינוי במרחב השמות לא יעזור.

systemctl show [email protected] -p PrivateTmp -p User -p Group -p RuntimeDirectory
systemctl show [email protected] -p MainPID --value
sudo ls -l /proc/PID/root/tmp/client-state

נתיב שורש התהליך חושף את תצוגת מערכת הקבצים של השירות עצמו, בכפוף לבדיקות הרשאה על אותו תהליך כל עוד הוא פועל. קרא את היומן של היחידה באותו מושב, כי שגיאת כתיבה וקובץ חסר מתבלבלים בקלות לאחר שמישהו כבר החליט על הסיבה.

תן לנתונים משותפים מיקום מפורש

נתונים שרק השירות צריך שייכים לספרייה הזמנית הפרטית שלו. נתונים שתהליך אחר חייב לקרוא זקוקים לנתיב מוגדר לשניהם, עם בעלים, מצב ותפוגה מוצהרים. החלט איזה משני המקרים יש לך לפני שתערוך את היחידה. רוב התקריות הללו נובעות מהתייחסות לקובץ פרטי כאל קובץ משותף.

[Service]
RuntimeDirectory=openvpn-hook-office
RuntimeDirectoryMode=0750

ספריית זמן ריצה מציבה את התיקייה תחת אזור זמן הריצה של המערכת, יוצרת אותה עבור המשתמש והקבוצה המוגדרים של היחידה ומסירה אותה כשהיחידה נעצרת. הוסף אותה באמצעות drop-in כדי שיחידת החבילה תישאר שלמה, ואז טען מחדש את המנהל והפעל מחדש את המופע הזה, תוך קבלה שהלקוחות שלו יתחברו מחדש.

שמור כל ספריית זמן ריצה שהיחידה המותקנת כבר דורשת. החלפת הרשימה במקום הוספה אליה היא דרך נפוצה לשבור תכונה לא קשורה שאיש אינו מקשר לשינוי.

שתי שכבות הרשאה יכולות לחלוק

מנהל השירות יוצר את הספרייה עבור המשתמש המוגדר של היחידה, בעוד שדמון ה-VPN יכול לרדת בנפרד לחשבון משלו לפני הפעלת הוק חיבור. אלה שכבות שונות, והן יכולות למנות זהויות שונות.

ספרייה בבעלות root עם מצב מגביל נראית היטב לדמון שכבר ויתר על הרשאות, ועדיין אינה ניתנת לכתיבה על ידו. השגיאה נקראת אז כבעיית הרשאה למרות שהנתיב קיים בדיוק במקום שציפית. השווה את בעל הספרייה לזהות שההוק מדווח. כשהם שונים, המצב מעולם לא היה השאלה.

בדוק את הזהות שתחתיה ההוק באמת פועל לפני שינוי הבעלות. שינוי משתמש ההפעלה של השירות כדי לתקן ספרייה יכול לשנות גישה להתקנים והרשאות רשת במקומות אחרים, וזה מחיר גבוה לבעיה קטנה.

אמת את כל ההעברה

אשר ארבעה דברים בבת אחת: ההוק כותב תחת זהותו האמיתית, הקורא המיועד יכול לצרוך את הקובץ, משתמשים לא קשורים לא יכולים, ועצירת היחידה מנקה כמתוכנן. הופעת קובץ בספרייה הזמנית המשותפת של המארח אינה דרישה, והיא בדרך כלל סימן שההחלפה מעולם לא קיבלה נתיב משל עצמה. בדוק את הקורא לאחר הפעלה מחדש, לא רק במהלך הריצה הראשונה. התנהגות הניקוי היא חלק מהתכנון, לכן התבונן בה במקום להניח אותה.

מצב מתמיד שייך למקום עם תוחלת חיים מתאימה, כי ספריית זמן ריצה נועדה להיעלם. בחר את המיקום לפי תוחלת חיים ולא לפי נוחות. ההרגל הזה מונע את הגרסה הבאה של אותה חקירה.