כדי לפטור את Glibc מבעיית 2038, מוצע להפסיק להשתמש ב-utmp

Thorsten Kukuk, מנהיג צוות פיתוח הטכנולוגיה העתידית ב-SUSE (צוות הטכנולוגיה העתידית, מפתח את openSUSE MicroOS ו-SLE Micro), שהוביל בעבר את פרויקט SUSE LINUX Enterprise Server במשך 10 שנים, הציע להיפטר מקובץ /var/run/utmp בהפצות כדי לטפל באופן מלא בבעיית 2038 ב-Glibc. כל היישומים המשתמשים ב-utmp, wtmp ו-lastlog מוצעים להמרה לקבלת רשימת משתמשים המשתמשים ב-systemd-login.

ב-19 בינואר 2038, מוני הזמן הספציפיים שצוינו על ידי סוג 32 סיביות time_t יעלו על גדותיהם. Glibc, למרות שהציגה סוג time_t של 64 סיביות, ממשיכה להשתמש בסוג time_t של 32 סיביות במקרים מסוימים בפלטפורמות של 64 סיביות כדי לשמור על תאימות עם יישומי שטח משתמש של 32 סיביות. מקרה אחד כזה הוא קובץ /var/run/utmp, המאחסן נתונים על משתמשים המחוברים כעת למערכת. שדה הזמן ב-utmp מצוין באמצעות ערך time_t של 32 סיביות.

פשוט החלפת שדה הזמן ב-utmp מסוג 32-bit ל-64-bit לא תעבוד, מכיוון שזה יוביל לשינוי ב-Glibc ABI (הסוג ישתנה בפונקציות כמו login(), getutid() ו-utmpname ()) ושבירת תאימות עם יישומים המשתמשים ב-utmp, כולל w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm מנהלי תצוגה, emacs, openssh, qemu, samba, rsyslog וכו'. בשל שפע המלכודות האפשריות והמורכבות, הרעיון של החלפת סוג time_t ב-utmp נדחה על ידי מפתחי Glibc. מאותה סיבה, האפשרות להשתמש בשטח הפנוי הזמין במבנה utmp להוספת שדה זמן נוסף של 64 סיביות נמחקה.

בנוסף, שינוי ה-type bit depth ב-utmp לא פותר בעיות קיימות אחרות, שגם מהן הייתי רוצה להיפטר. לדוגמה, כתיבה ל-utmp דורשת זכויות מיוחדות, מה שמחייב להעניק לתהליכים הרשאות נוספות. בעיה נוספת היא שארכיטקטורת utmp מאפשרת למשתמשים מקומיים לבצע התקפות DoS, מה שמוביל לשיבוש שירות utmp באמצעות מניפולציה של נעילות קבצים, מה שלא מאפשר להיות בטוח שהתכנים של utmp משקפים את המצב האמיתי במערכת. הוצע להשתמש בתהליך רקע נוסף כדי לטפל בגישה ל-utmp, אך עבור משימות כאלה כבר קיים תהליך של systemd-login והשקת תהליך מיוחד אחר אינו רצוי (יישומים יצטרכו להעביר נתונים לשני מטפלים בו זמנית).

יחד עם זאת, גם כאשר פותרים את הבעיה עם התקפות DoS, התוכן של utmp נשאר מידעי בלבד ואינו מבטיח השתקפות של המציאות. לדוגמה, אמולטורים ומרבבי מסוף שונים משקפים את מצבם בצורה שונה - הפעלת חמישה מסופי GNOME תגרום לכך שמשתמש אחד ישתקף ב-utmp, והשקת חמישה מסופי konsole או xterm ב-KDE תגרום לשישה. ההתנהגות של מסך ו-tmux שונה באופן דומה: במקרה הראשון, כל סשן נספר כמשתמש נפרד, ובשני, רק משתמש אחד משתקף עבור כל הפגישות.

כתוצאה מכך, כפתרון הפשוט ביותר, מוצע להעביר את כל היישומים לשימוש בשירות systemd-login האלטרנטיבי שכבר קיים, ולאחר שאין תוכניות נוכחיות הניגשות ל-utmp, להפסיק את ההקלטה ל-utmp. כדי להחליף את wtmp, מוצע להכין ממשקי תוכנה לכתיבה וקריאה של מידע על משתמשים המשתמשים ב-systemd-journald. בסיס הקוד של המהדורה הבאה של systemd 254 כבר כולל את הפונקציונליות הדרושה כדי לספק נתוני החלפת utmp באמצעות libsystemd באמצעות sd-login.h API או באמצעות DBUS.

מקור: OpenNet.ru