Thorsten Kukuk، SUSE میں مستقبل کے ٹیکنالوجی ڈویلپمنٹ گروپ کے رہنما (فیوچر ٹیکنالوجی ٹیم، OpenSUSE MicroOS اور SLE Micro تیار کرتی ہے)، جنہوں نے پہلے 10 سال تک SUSE LINUX انٹرپرائز سرور پروجیکٹ کی قیادت کی، نے تجویز پیش کی کہ /var/run/utmp فائل سے چھٹکارا حاصل کریں۔ Glibc میں 2038 کے مسئلے کو مکمل طور پر حل کرنے کے لیے تقسیم میں۔ utmp، wtmp اور lastlog استعمال کرنے والی تمام ایپلیکیشنز کو systemd-logind استعمال کرنے والے صارفین کی فہرست حاصل کرنے کے لیے تبدیل کرنے کی تجویز ہے۔
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 میں تبدیلی کا باعث بنے گا (یہ قسم لاگ ان()، getutid() اور utmpname جیسے فنکشنز میں بدل جائے گی۔ ()) اور ایپلی کیشنز کے ساتھ مطابقت کو توڑنا جو utmp استعمال کرتی ہیں، بشمول w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm ڈسپلے مینیجرز, emacs, openssh, qemu, samba, rsyslog, وغیرہ۔ ممکنہ نقصانات اور پیچیدگی کی کثرت کی وجہ سے، utmp میں time_t قسم کو تبدیل کرنے کے خیال کو Glibc ڈویلپرز نے مسترد کر دیا تھا۔ اسی وجہ سے، اضافی 64 بٹ ٹائم فیلڈ کو شامل کرنے کے لیے utmp ڈھانچے میں دستیاب خالی جگہ کو استعمال کرنے کے اختیار کو مسترد کر دیا گیا۔
اس کے علاوہ، utmp میں قسم کی bit depth کو تبدیل کرنے سے دیگر موجودہ مسائل حل نہیں ہوتے، جن سے میں بھی چھٹکارا حاصل کرنا چاہوں گا۔ مثال کے طور پر، utmp پر لکھنے کے لیے خصوصی حقوق کی ضرورت ہوتی ہے، جس کے لیے عمل کو اضافی مراعات دینے کی ضرورت ہوتی ہے۔ ایک اور مسئلہ یہ ہے کہ utmp فن تعمیر مقامی صارفین کو DoS حملے کرنے کی اجازت دیتا ہے، جس کے نتیجے میں فائل لاک میں ہیرا پھیری کے ذریعے utmp سروس میں خلل پڑتا ہے، جس سے یہ یقینی بنانا ناممکن ہو جاتا ہے کہ utmp کے مواد سسٹم میں حقیقی حالت کی عکاسی کرتے ہیں۔ utmp تک رسائی کو سنبھالنے کے لیے ایک اضافی پس منظر کے عمل کو استعمال کرنے کی تجویز پیش کی گئی تھی، لیکن اس طرح کے کاموں کے لیے پہلے سے ہی ایک systemd-logind عمل موجود ہے اور ایک اور خصوصی عمل شروع کرنا مناسب نہیں ہے (درخواستوں کو بیک وقت دو ہینڈلرز کو ڈیٹا منتقل کرنا پڑے گا)۔
ایک ہی وقت میں، DoS حملوں سے مسئلہ حل کرتے وقت بھی، utmp کے مواد صرف معلوماتی رہتے ہیں اور حقیقت کی عکاسی کی ضمانت نہیں دیتے۔ مثال کے طور پر، مختلف ایمولیٹرز اور ٹرمینل ملٹی پلیکسرز اپنی حالت کو مختلف طریقے سے ظاہر کرتے ہیں - پانچ GNOME ٹرمینلز شروع کرنے کے نتیجے میں ایک صارف utmp میں جھلکتا ہے، اور KDE میں پانچ کونسول یا xterm ٹرمینلز شروع کرنے کے نتیجے میں چھ ہوں گے۔ اسکرین اور tmux کا رویہ اسی طرح مختلف ہے: پہلی صورت میں، ہر سیشن کو ایک الگ صارف کے طور پر شمار کیا جاتا ہے، اور دوسرے میں، تمام سیشنز کے لیے صرف ایک صارف کی عکاسی ہوتی ہے۔
نتیجے کے طور پر، سب سے آسان حل کے طور پر، یہ تجویز ہے کہ پہلے سے موجود متبادل systemd-logind سروس کو استعمال کرنے کے لیے تمام ایپلیکیشنز کو منتقل کیا جائے اور، utmp تک رسائی حاصل کرنے والے کوئی موجودہ پروگرام نہ ہونے کے بعد، utmp پر ریکارڈنگ بند کر دیں۔ ڈبلیو ٹی ایم پی کو تبدیل کرنے کے لیے، سسٹم ڈی جرنلڈ استعمال کرنے والے صارفین کے بارے میں معلومات لکھنے اور پڑھنے کے لیے سافٹ ویئر انٹرفیس تیار کرنے کی تجویز ہے۔ systemd 254 کی اگلی ریلیز کے لیے کوڈ بیس میں پہلے سے ہی ضروری فعالیت شامل ہے تاکہ libsystemd کے ذریعے sd-login.h API کا استعمال کرتے ہوئے یا DBUS کے ذریعے utmp متبادل ڈیٹا فراہم کیا جا سکے۔
ماخذ: opennet.ru