Glibc এর Y2038 সমস্যা থেকে পরিত্রাণ পেতে utmp ব্যবহার বন্ধ করার প্রস্তাব করা হয়েছে

থরস্টেন কুকুক, SUSE-এর ভবিষ্যত প্রযুক্তি উন্নয়ন দলের নেতা (ফিউচার টেকনোলজি টিম, openSUSE MicroOS এবং SLE Micro ডেভেলপ করে), যিনি পূর্বে 10 বছর ধরে SUSE LINUX এন্টারপ্রাইজ সার্ভার প্রকল্পের নেতৃত্ব দিয়েছিলেন, তিনি /var/run/utmp ফাইল থেকে মুক্তি পাওয়ার পরামর্শ দিয়েছেন Glibc-এর 2038 সমস্যা সম্পূর্ণরূপে সমাধানের জন্য বিতরণে। utmp, wtmp এবং lastlog ব্যবহার করে সমস্ত অ্যাপ্লিকেশনকে systemd-logind ব্যবহার করে ব্যবহারকারীদের তালিকা পেতে রূপান্তরিত করার প্রস্তাব করা হয়েছে।

19 জানুয়ারী, 2038-এ, 32-বিট time_t টাইপের দ্বারা নির্দিষ্ট করা যুগান্তকারী সময় কাউন্টারগুলি ওভারফ্লো হবে৷ Glibc, একটি 64-বিট time_t টাইপ প্রবর্তন করা সত্ত্বেও, 32-বিট ব্যবহারকারী স্পেস অ্যাপ্লিকেশনগুলির সাথে সামঞ্জস্য বজায় রাখতে 64-বিট প্ল্যাটফর্মে কিছু ক্ষেত্রে একটি 32-বিট time_t টাইপ ব্যবহার করা অব্যাহত রাখে। এরকম একটি কেস হল /var/run/utmp ফাইল, যা বর্তমানে সিস্টেমে লগ ইন করা ব্যবহারকারীদের তথ্য সংরক্ষণ করে। utmp-এ সময় ক্ষেত্রটি একটি 32-বিট time_t মান ব্যবহার করে নির্দিষ্ট করা হয়।

কেবলমাত্র একটি 32-বিট থেকে 64-বিট টাইপে utmp-এ টাইম ফিল্ড প্রতিস্থাপন করা কাজ করবে না, কারণ এটি Glibc ABI-তে পরিবর্তন আনবে (টাইপটি লগইন(), getutid() এবং utmpname-এর মতো ফাংশনে পরিবর্তন হবে ()) এবং w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm ডিসপ্লে ম্যানেজার, emacs, openssh, qemu, samba, rsyslog, ইত্যাদি সহ utmp ব্যবহার করে এমন অ্যাপ্লিকেশনগুলির সাথে সামঞ্জস্যতা ভাঙা। সম্ভাব্য অসুবিধা এবং জটিলতার প্রাচুর্যের কারণে, utmp-এ time_t টাইপ প্রতিস্থাপনের ধারণা Glibc ডেভেলপারদের দ্বারা প্রত্যাখ্যান করা হয়েছিল। একই কারণে, একটি অতিরিক্ত 64-বিট টাইম ফিল্ড যোগ করার জন্য utmp কাঠামোতে উপলব্ধ ফাঁকা স্থান ব্যবহার করার বিকল্পটি বাতিল করা হয়েছে।

উপরন্তু, utmp এ টাইপ বিট গভীরতা পরিবর্তন করা অন্যান্য বিদ্যমান সমস্যার সমাধান করে না, যা আমি পরিত্রাণ পেতে চাই। উদাহরণস্বরূপ, utmp-এ লেখার জন্য বিশেষ অধিকারের প্রয়োজন হয়, যার জন্য প্রসেসগুলিকে অতিরিক্ত সুযোগ-সুবিধা দেওয়া প্রয়োজন। আরেকটি সমস্যা হল যে utmp আর্কিটেকচার স্থানীয় ব্যবহারকারীদের DoS আক্রমণ চালানোর অনুমতি দেয়, যার ফলে ফাইল লকগুলির ম্যানিপুলেশনের মাধ্যমে utmp পরিষেবা ব্যাহত হয়, যা নিশ্চিত করা অসম্ভব করে তোলে যে utmp-এর বিষয়বস্তুগুলি সিস্টেমে বাস্তব অবস্থা প্রতিফলিত করে। utmp-এ অ্যাক্সেস পরিচালনা করার জন্য একটি অতিরিক্ত ব্যাকগ্রাউন্ড প্রক্রিয়া ব্যবহার করার প্রস্তাব করা হয়েছিল, কিন্তু এই ধরনের কাজের জন্য ইতিমধ্যেই একটি সিস্টেমড-লগইন্ড প্রক্রিয়া রয়েছে এবং অন্য একটি বিশেষ প্রক্রিয়া চালু করার পরামর্শ দেওয়া হয় না (অ্যাপ্লিকেশনগুলিকে একসাথে দুটি হ্যান্ডলারে ডেটা স্থানান্তর করতে হবে)।

একই সময়ে, এমনকি DoS আক্রমণের সাথে সমস্যা সমাধান করার সময়, utmp-এর বিষয়বস্তু শুধুমাত্র তথ্যগত থাকে এবং বাস্তবতার প্রতিফলনের গ্যারান্টি দেয় না। উদাহরণস্বরূপ, বিভিন্ন এমুলেটর এবং টার্মিনাল মাল্টিপ্লেক্সার তাদের অবস্থাকে ভিন্নভাবে প্রতিফলিত করে - পাঁচটি জিনোম টার্মিনাল চালু করার ফলে একজন ব্যবহারকারী utmp-এ প্রতিফলিত হবে, এবং KDE-তে পাঁচটি কনসোল বা xterm টার্মিনাল চালু করলে ছয়টি হবে। স্ক্রীন এবং tmux-এর আচরণ একইভাবে ভিন্ন: প্রথম ক্ষেত্রে, প্রতিটি সেশন একটি পৃথক ব্যবহারকারী হিসাবে গণনা করা হয়, এবং দ্বিতীয়টিতে, সমস্ত সেশনের জন্য শুধুমাত্র একজন ব্যবহারকারী প্রতিফলিত হয়।

ফলস্বরূপ, সবচেয়ে সহজ সমাধান হিসাবে, ইতিমধ্যে বিদ্যমান বিকল্প সিস্টেমড-লগইন্ড পরিষেবা ব্যবহার করার জন্য সমস্ত অ্যাপ্লিকেশন স্থানান্তর করার প্রস্তাব করা হয়েছে এবং utmp অ্যাক্সেস করার কোনো বর্তমান প্রোগ্রাম না থাকার পরে, utmp-এ রেকর্ডিং বন্ধ করুন। wtmp প্রতিস্থাপন করার জন্য, সিস্টেমড-জার্নাল্ড ব্যবহার করে ব্যবহারকারীদের সম্পর্কে তথ্য লেখা ও পড়ার জন্য সফ্টওয়্যার ইন্টারফেস প্রস্তুত করার প্রস্তাব করা হয়েছে। systemd 254-এর পরবর্তী রিলিজের কোডবেসে ইতিমধ্যেই sd-login.h API ব্যবহার করে বা DBUS-এর মাধ্যমে libsystemd-এর মাধ্যমে utmp প্রতিস্থাপন ডেটা প্রদানের প্রয়োজনীয় কার্যকারিতা অন্তর্ভুক্ত রয়েছে।

উত্স: opennet.ru