ٿورسٽن ڪوڪڪ، SUSE (اوپن SUSE مائڪرو او ايس ۽ SLE مائڪرو جو ڊولپر) ۾ فيوچر ٽيڪنالاجي ٽيم جو اڳواڻ، جيڪو اڳ ۾ 10 سالن تائين SUSE لينڪس انٽرپرائز سرور پروجيڪٽ جي اڳواڻي ڪري چڪو هو، Glibc سال 2038 جي مسئلي کي مڪمل طور تي حل ڪرڻ لاءِ /var/run/utmp فائل کي ڊسٽريبيوشن مان هٽائڻ جي تجويز پيش ڪئي. utmp، wtmp، ۽ lastlog استعمال ڪندڙ سڀني ايپليڪيشنن کي systemd-logind استعمال ڪندي صارف لسٽن کي حاصل ڪرڻ لاءِ منتقل ڪرڻ جي تجويز آهي.
19 جنوري 2038 تي، 32-bit time_t قسم پاران بيان ڪيل ايپوڪل ٽائيم ڪائونٽر اوور فلو ٿي ويندا. 64-bit time_t قسم جي تعارف جي باوجود، Glibc لائبريري 32-bit يوزر-اسپيس ايپليڪيشنن سان مطابقت برقرار رکڻ لاءِ 64-bit پليٽ فارمن تي ڪجهه ڪيسن ۾ 32-bit time_t قسم استعمال ڪرڻ جاري رکي ٿي. اهڙو ئي هڪ ڪيس /var/run/utmp فائل آهي، جيڪا هن وقت سسٽم تي لاگ ان ٿيل استعمال ڪندڙن بابت ڊيٽا محفوظ ڪري ٿي. utmp ۾ ٽائيم فيلڊ 32-bit time_t قدر استعمال ڪندي بيان ڪيو ويو آهي.
صرف 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، ۽ ٻيا شامل آهن. امڪاني نقصانن جي گهڻائي ۽ شامل پيچيدگي جي ڪري، utmp ۾ time_t قسم کي تبديل ڪرڻ جو خيال Glibc ڊولپرز پاران رد ڪيو ويو. ساڳئي سبب، utmp ڍانچي ۾ موجود خالي جاءِ کي استعمال ڪندي اضافي 64-bit ٽائيم فيلڊ شامل ڪرڻ جو اختيار رد ڪيو ويو.
وڌيڪ، utmp فائل جي قسم جي بٽ ڊيپٿ کي تبديل ڪرڻ سان ٻيا موجوده مسئلا حل نه ٿيندا آهن جن کي حل ڪرڻ به گهربل هوندو. مثال طور، utmp تي لکڻ لاءِ خاص اجازتن جي ضرورت هوندي آهي، جنهن لاءِ پروسيس کي اضافي مراعات ڏيڻ جي ضرورت هوندي آهي. ٻيو مسئلو اهو آهي ته utmp آرڪيٽيڪچر مقامي استعمال ڪندڙن کي DoS حملي ڪرڻ جي اجازت ڏئي ٿو جيڪي فائل لاڪ کي هٿي وٺرائڻ سان utmp سروس کي خراب ڪن ٿا، اهو ناممڪن بڻائي ٿو ته اهو يقيني بڻايو وڃي ته utmp مواد اصل سسٽم جي حالت کي ظاهر ڪري ٿو. utmp تائين رسائي کي سنڀالڻ لاءِ هڪ اضافي پس منظر جي عمل کي استعمال ڪرڻ جي تجويز ڏني وئي هئي، پر اهڙن ڪمن لاءِ سسٽم ڊي-لاگ انڊ عمل اڳ ۾ ئي موجود آهي، ۽ ٻيو خاص عمل شروع ڪرڻ غير عملي آهي (ايپليڪيشنن کي هڪ ئي وقت ٻن هينڊلرن کي ڊيٽا منتقل ڪرڻو پوندو).
جيتوڻيڪ DoS حملي جي مسئلي کي حل ڪرڻ سان، utmp مواد صرف معلوماتي رهي ٿو ۽ حقيقي حقيقت کي ظاهر ڪرڻ جي ضمانت نه آهي. مثال طور، مختلف ٽرمينل ايموليٽر ۽ ملٽي پلڪسر پنهنجي حالت کي مختلف طريقي سان ظاهر ڪن ٿا: پنج GNOME ٽرمينل لانچ ڪرڻ جي نتيجي ۾ هڪ صارف utmp ۾ ظاهر ٿيندو، جڏهن ته KDE ۾ پنج ڪنسول يا xterm ٽرمينل لانچ ڪرڻ جي نتيجي ۾ ڇهه ٿيندا. ساڳئي طرح، اسڪرين ۽ tmux مختلف طريقي سان عمل ڪن ٿا: پهرين ۾، هر سيشن کي هڪ الڳ صارف طور شمار ڪيو ويندو آهي، جڏهن ته بعد ۾، سڀني سيشنن ۾ صرف هڪ صارف ڏيکاريو ويندو آهي.
آخرڪار، تجويز ڪيل آسان حل اهو آهي ته سڀني ايپليڪيشنن کي موجوده متبادل سروس، systemd-logind ڏانهن منتقل ڪيو وڃي، ۽، هڪ ڀيرو utmp تائين رسائي حاصل ڪرڻ لاءِ وڌيڪ لاڳاپيل پروگرام نه هجن، ته پوءِ utmp ڏانهن لکڻ بند ڪيو وڃي. wtmp کي تبديل ڪرڻ لاءِ، systemd-journald استعمال ڪندي صارف جي معلومات لکڻ ۽ پڙهڻ لاءِ API ٺاهڻ جي تجويز آهي. systemd 254 جي ايندڙ رليز لاءِ ڪوڊ بيس ۾ اڳ ۾ ئي sd-login.h API استعمال ڪندي يا DBUS ذريعي libsystemd ذريعي متبادل utmp ڊيٽا مهيا ڪرڻ لاءِ ضروري ڪم شامل آهن.
جو ذريعو: opennet.ru
