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