Masalah tahun 2038 boleh menyebabkan sebahagian daripada perisian gagal pada tahun itu. Masalahnya mempengaruhi program yang menggunakan perwakilan masa berasaskan POSIX.
Thorsten Kukuk, Ketua pasukan daripada Teknologi Masa Depan SUSE (Pasukan Teknologi Masa Depan, membangunkan openSUSE MicroOS dan SLE Micr ), yang sebelum ini mengetuai projek SUSE LINUX Enterprise Server selama 10 tahun, mencadangkan menyingkirkan fail /var/run/utmp dalam pengedaran untuk menangani sepenuhnya isu Y2038 dalam Glibc.
Dengannya adalah dicadangkan untuk memindahkan semua aplikasi yang menggunakan utmp, wtmp dan lastlog untuk mendapatkan senarai pengguna menggunakan systemd-logind.
Pada 19 Januari 2038, pemasa akan melimpah tempoh yang ditetapkan mengikut jenis time_t 32-bit. Dalam Glibc, walaupun jenis time_t 64-bit diperkenalkan, untuk mengekalkan keserasian dengan aplikasi ruang pengguna 32-bit, jenis time_t 32-bit masih digunakan dalam beberapa kes pada platform 64-bit.
Terdapat dua masalah utama dengan utmp/utmpx dengan glibc dihidupkan contohnya x86-64:
Medan time_t 32-bit digunakan untuk masa itu, yang akan melimpah pada 2038
Terdapat isu reka bentuk yang membenarkan serangan DoS ( utmp/wtmp menyekat membenarkan pengguna yang tidak mempunyai hak untuk menafikan perkhidmatan )
Analisis masalah kedua oleh pembangun glibc menunjukkan bahawa daemon tambahan diperlukan untuk mengendalikan akses utmp/utmpx.Walaupun ada beberapa masalah lagi...
Satu kes sedemikian ialah fail /var/run/utmp, yang menyimpan data tentang pengguna yang sedang disambungkan ke sistem. Medan masa dalam utmp ditetapkan menggunakan nilai time_t 32-bit.
Disebutkan bahawa, hanya menukar medan dalam utmp dari semasa ke semasa daripada jenis 32-bit kepada jenis 64-bit tidak akan berfungsi, kerana ini akan mengubah Glibc ABI (jenis akan berubah dalam fungsi seperti log masuk(), getutid() dan utmpname()) dan memecahkan keserasian dengan aplikasi yang menggunakan utmp, termasuk w, who, uptime, log masuk, su, sudo, useradd , systemd, sysvinit, tcsh, pengurus paparan xterm, emacs, openssh, qemu, samba, rsyslog, dsb.
Oleh kerana banyak kemungkinan perangkap dan ketekunan, pemaju dari Glibc menolak idea untuk menggantikan panjang bit jenis time_t dalam utmp. Atas sebab yang sama, pilihan untuk menggunakan ruang yang tersedia dalam struktur utmp untuk menambah medan masa 64-bit tambahan telah dialih keluar.
Juga, menukar kedalaman bit jenis dalam utmp tidak menyelesaikan masalah sedia ada lain, contohnya, menulis kepada utmp memerlukan kebenaran khas, yang memerlukan proses untuk diberikan keistimewaan tambahan. Masalah lain ialah seni bina utmp membolehkan pengguna tempatan melakukan serangan DoS yang memecahkan perkhidmatan utmp dengan memanipulasi kunci fail, menjadikannya mustahil untuk memastikan bahawa kandungan utmp mencerminkan keadaan sebenar sistem.
Ia dicadangkan untuk menggunakan proses latar belakang tambahan untuk mengendalikan akses kepada utmp, tetapi untuk tugas sedemikian sudah ada proses log masuk systemd dan tidak disyorkan untuk memulakan satu lagi proses khusus (aplikasi perlu memindahkan data kepada dua pengawal pada masa yang sama).
Pada masa yang sama, walaupun dengan menyelesaikan masalah dengan serangan DoS, kandungan utmp kekal hanya bermaklumat, tanpa menjamin gambaran realiti.
Contohnya, emulator dan pemultipleks terminal yang berbeza mencerminkan keadaan mereka secara berbeza: menjalankan lima terminal GNOME akan menyebabkan satu pengguna dicerminkan dalam utmp, manakala menjalankan lima terminal konsole atau xterm dalam KDE akan menghasilkan enam. Begitu juga, tingkah laku skrin dan tmux berbeza, dalam kes pertama setiap sesi dikira sebagai pengguna yang berasingan dan dalam kedua hanya satu pengguna ditunjukkan untuk semua sesi.
Akibatnya, sebagai penyelesaian yang paling mudah, adalah dicadangkan untuk mengalihkan semua aplikasi untuk menggunakan perkhidmatan systemd-login alternatif sudah sedia ada dan, selepas tiada program sebenar mengakses utmp, berhenti menulis kepada utmp. Untuk menggantikan wtmp, adalah dicadangkan untuk menyediakan API untuk menulis dan membaca maklumat tentang pengguna menggunakan systemd-journald.
Akhir sekali, perlu dinyatakan bahawa asas kod untuk versi seterusnya systemd 254 sudah termasuk fungsi yang diperlukan untuk menyediakan data utmp gantian melalui libsystemd menggunakan API sd-login.ho melalui DBUS.
Jika anda berminat untuk mengetahui lebih lanjut mengenainya, anda boleh rujuk butirannya Dalam pautan berikut.