Thorsten Kukuk, pemimpin kelompok pengembangan teknologi masa depan di SUSE (Tim Teknologi Masa Depan, mengembangkan openSUSE MicroOS dan SLE Micro), yang sebelumnya memimpin proyek SUSE LINUX Enterprise Server selama 10 tahun, menyarankan untuk membuang file /var/run/utmp dalam distribusi untuk sepenuhnya mengatasi masalah tahun 2038 di Glibc. Semua aplikasi yang menggunakan utmp, wtmp dan lastlog diusulkan untuk dikonversi untuk mendapatkan daftar pengguna menggunakan systemd-logind.
Pada tanggal 19 Januari 2038, penghitung waktu penting yang ditentukan oleh tipe time_t 32-bit akan meluap. Glibc, meskipun memperkenalkan tipe time_t 64-bit, tetap menggunakan tipe time_t 32-bit dalam beberapa kasus pada platform 64-bit untuk menjaga kompatibilitas dengan aplikasi ruang pengguna 32-bit. Salah satu kasusnya adalah file /var/run/utmp, yang menyimpan data tentang pengguna yang sedang login ke sistem. Bidang waktu di utmp ditentukan menggunakan nilai time_t 32-bit.
Mengganti kolom waktu di utmp dari tipe 32-bit ke 64-bit saja tidak akan berfungsi, karena ini akan menyebabkan perubahan pada Glibc ABI (tipe akan berubah pada fungsi seperti login(), getutid() dan utmpname ()) dan merusak kompatibilitas dengan aplikasi yang menggunakan utmp, termasuk w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display manager, emacs, openssh, qemu, samba, rsyslog, dll. Karena banyaknya kemungkinan jebakan dan kerumitan, gagasan untuk mengganti tipe time_t dengan utmp ditolak oleh pengembang Glibc. Untuk alasan yang sama, opsi untuk menggunakan ruang kosong yang tersedia dalam struktur utmp untuk menambahkan bidang waktu 64-bit tambahan telah dibuang.
Selain itu, mengubah jenis kedalaman bit di utmp tidak menyelesaikan masalah lain yang ada, yang juga ingin saya hilangkan. Misalnya, menulis ke utmp memerlukan hak khusus, yang mengharuskan proses diberikan hak istimewa tambahan. Masalah lainnya adalah arsitektur utmp memungkinkan pengguna lokal untuk melakukan serangan DoS, yang menyebabkan gangguan layanan utmp melalui manipulasi kunci file, sehingga tidak mungkin untuk memastikan bahwa konten utmp mencerminkan keadaan sebenarnya dalam sistem. Diusulkan untuk menggunakan proses latar belakang tambahan untuk menangani akses ke utmp, tetapi untuk tugas seperti itu sudah ada proses systemd-logind dan tidak disarankan untuk meluncurkan proses khusus lainnya (aplikasi harus mentransfer data ke dua penangan secara bersamaan).
Pada saat yang sama, bahkan ketika menyelesaikan masalah dengan serangan DoS, konten utmp tetap hanya bersifat informasi dan tidak menjamin cerminan kenyataan. Misalnya, emulator dan multiplekser terminal yang berbeda mencerminkan keadaannya secara berbeda - meluncurkan lima terminal GNOME akan menghasilkan satu pengguna yang tercermin dalam utmp, dan meluncurkan lima terminal konsole atau xterm di KDE akan menghasilkan enam pengguna. Perilaku screen dan tmux juga berbeda: dalam kasus pertama, setiap sesi dihitung sebagai pengguna terpisah, dan dalam kasus kedua, hanya satu pengguna yang tercermin untuk semua sesi.
Akibatnya, sebagai solusi paling sederhana, diusulkan untuk mentransfer semua aplikasi untuk menggunakan layanan systemd-logind alternatif yang sudah ada dan, setelah tidak ada program yang mengakses utmp, berhenti merekam ke utmp. Untuk menggantikan wtmp, diusulkan untuk menyiapkan antarmuka perangkat lunak untuk menulis dan membaca informasi tentang pengguna menggunakan systemd-journald. Basis kode untuk rilis berikutnya dari systemd 254 sudah menyertakan fungsionalitas yang diperlukan untuk menyediakan data pengganti utmp melalui libsystemd menggunakan API sd-login.h atau melalui DBUS.
Sumber: opennet.ru