Thorsten Kukuk، په SUSE کې د راتلونکي ټیکنالوژۍ ټیم مشر (د راتلونکي ټیکنالوژۍ ټیم، OpenSUSE MicroOS او SLE Micro ته وده ورکوي)، چې مخکې یې د 10 کلونو لپاره د SUSE LINUX Enterprise Server پروژې مشري کوله، وړاندیز وکړ چې د /var/run/utmp فایل څخه ځان خلاص کړي. په Glibc کې د Y2038 ستونزې په بشپړ ډول حل کولو لپاره توزیع. ټول غوښتنلیکونه چې utmp، wtmp، او lastlog کاروي وړاندیز کیږي چې د سیسټمd-logind په کارولو سره د کاروونکو لیست ترلاسه کولو لپاره لیږدول شي.
د جنورۍ په 19، 2038 کې، د 32-bit time_t ډول لخوا ټاکل شوي د وخت وخت شمیرونکي به ډیریږي. په Glibc کې، د 64-bit time_t ډول معرفي کولو سره سره، د 32-bit کاروونکي-ځای غوښتنلیکونو سره مطابقت ساتلو لپاره، د 64-bit time_t ډول لاهم په ځینو مواردو کې په 32-bit پلیټ فارمونو کې کارول کیږي. یوه ورته قضیه د /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 کې د وخت_t ډول بټ اوږدوالي ځای په ځای کولو نظر د ګلیبیک پراختیا کونکو لخوا رد شو. د ورته دلیل لپاره، د utmp جوړښت کې د شته ځای کارولو اختیار د اضافي 64-bit وخت ساحه اضافه کولو لپاره پریښودل شوی.
سربیره پردې ، په utmp کې د ډول بټ ژورتیا بدلول نورې موجوده ستونزې نه حل کوي ، کوم چې زه یې هم لرې کول غواړم. د مثال په توګه، utmp ته لیکل ځانګړي اجازې ته اړتیا لري، کوم چې اضافي امتیازاتو ته اړتیا لري چې پروسې ته ورکړل شي. بله ستونزه دا ده چې د utmp جوړښت محلي کاروونکو ته اجازه ورکوي چې د DoS بریدونه ترسره کړي چې د فایل لاکونو د مینځلو له لارې د utmp خدمت ماتوي، دا ناشونې کوي چې ډاډ ترلاسه شي چې د utmp مینځپانګې په سیسټم کې اصلي حالت منعکس کوي. utmp ته د لاسرسي اداره کولو لپاره د اضافي شالید پروسې کارولو وړاندیز شوی و ، مګر د داسې کارونو لپاره لا دمخه د سیسټم - ننوتلو پروسه شتون لري او د بل ځانګړي پروسې پیل کول د مشورې وړ ندي (غوښتنلیکونه باید په ورته وخت کې دوه هینډلرانو ته ډیټا لیږد کړي) .
په ورته وخت کې، حتی کله چې د DoS بریدونو سره د ستونزې حل کول، د utmp منځپانګې یوازې معلوماتي پاتې کیږي، د واقعیت انعکاس تضمین نه کوي. د مثال په توګه، مختلف ټرمینل ایمولیټرونه او ملټي پلیکسر خپل حالت په مختلف ډول منعکس کوي - د پنځو GNOME ټرمینالونو چلول به په پایله کې یو کارن په utmp کې منعکس شي، پداسې حال کې چې په KDE کې د پنځو کنسول یا xterm ترمینلونو چلول به شپږ پایله ولري. په ورته ډول، د سکرین او tmux چلند توپیر لري، په لومړي حالت کې هره ناسته د جلا کارونکي په توګه شمیرل کیږي، او په دویمه کې یوازې یو کارن د ټولو غونډو لپاره منعکس کیږي.
د پایلې په توګه، د ساده حل په توګه، دا وړاندیز کیږي چې ټول غوښتنلیکونه د پخوانۍ موجوده بدیل سیسټم-لاګ انډ خدمت کارولو لپاره انتقال کړي، او وروسته له دې چې هیڅ حقیقي پروګرامونه utmp ته لاسرسی نلري، utmp ته لیکل ودروي. د wtmp ځای په ځای کولو لپاره، دا وړاندیز شوی چې د سیسټمd-journald کارولو کاروونکو په اړه د معلوماتو لیکلو او لوستلو لپاره APIs چمتو کړي. د سیسټمډ 254 راتلونکي خوشې کولو لپاره کوډبیس دمخه د sd-login.h API په کارولو یا د DBUS له لارې د libsystemd له لارې د utmp ډیټا بدلولو لپاره اړین دندې شاملې دي.
سرچینه: opennet.ru