בונים מערכת בטוחה

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

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

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

כמעט נכון.

כאשר יש בעיית אבטחה באחת הספריות, מסתבר שכבר בכלל בכלל לא פשוט להחליף אותה. לא מזמן התגלתה בעיית אבטחה בפיענוח תמונות מסוג jpeg ע”י ספריה של מיקרוסופט בשם “GDI+‎”. והנה, מסתבר שבכלל בכלל לא פשוט לבדוק האם אתה פגיע. אז, אוקיי, הכלי של מיקרוסופט לא מסוגל להגיד לכם. אוקיי.

עכשיו, אבל, CERT מוציאה רשימה ארוכה ארוכה של תוכנות שפגיעות. בהצלחה בשידרוג.

ולכל מי שאומר “אבל בלינוקס זה אותו הדבר”…..

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

שחר

מאת

שחר שמש

מייסד–שותף וחבר ועד בתנועה לזכויות דיגיטליות מייסד שותף בעמותת „המקור”. פעיל קוד פתוח. מפתח שפת התכנות Practical

5 תגובות בנושא “בונים מערכת בטוחה”

  1. 1. היתרון של ספריות משותפות הוא לא רק בדיסק אלא גם (ובעיקר, IMHO) בשיתוף הקוד בזכרון המרכזי. כשהקוד מגיע מקבצים שונים הוא גם נמצא בעותקים מרובים גם שם, ואילו כשהוא מגיע מאותו קובץ יש רק עותק אחד שלו בזיכרון המרכזי ואולי יותר חשוב מזה גם בזכרון המטמון של המעבד המרכזי, למשל תאר את printf – שנמצאת בטח בשימוש של כל תוכנת C.
    2. המנגנונים של לינוקס (או לפחות אלו של דביאן, אבל נדמה לי שגם הפצות מבוססות RPM עושות את זה היום) לא רק מאפשרים לשתף את הספריות אלא גם מאפשרים למנגנון ההתקנה למנוע התקנת גרסאות של תוכנה ושל ספריה שלא מתאימות אחת לשניה (שזו הסיבה ל-DLL Hell מלחתחילה, לא?)

  2. מהנסיון שלי, יש DLL Hell גם בלינוקס. אבל זה מתבטא בצורה אחרת – אם אני לא משדרג לגירסא חדשה יותר של תפוצה (כמו RedHat) אז לאחר כמה שנים אני מגלה שכדי להתקין חבילת תוכנה חדשה, אני צריך להתקין גירסאות מעודכנות של כל מיני ספריות.
    (לאחרונה החלטתי לעבור לדביאן מסיבה זו).

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

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

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

      ספריות שמנוהלות ע"י libtool מאפשרות מספורי גרסא של התקנות side by side. מנגנון חביב שמתמש ב-symbolic links כדי לאפשר התקנות כמה גרסאות של אותה הספריה על אותו המחשב, ומאפשר בדיקה קלה ומהירה כדי להבין באילו גרסאות של ממשק אתה מסוגל לתמוך כרגע, ובאמצעות איזה קובץ.

      שחר

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

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

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

        יש פתרון שישביע את רצוני בחדר המשחקים וגם בחדר העבודה?

        1. אין פה ויכוח. יש פה, לכל היותר, אי הסכמה קלה.

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

          לגבי מנגנון שיענה על כל הצרכים – תחשוב על המנגנון הבא:
          קנית simcity, קיבלת עם זה DEB של התוכנה, ושל כל התלויות שלה. איפה הבעיה? זה שהתוכנה מגיעה על כמה קבצים במקום על אחד? אז מה?

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

          שחר

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

Bear