Thorsten Kukuk, ketua Pasukan Teknologi Masa Depan di SUSE (Pasukan Teknologi Masa Depan, membangunkan openSUSE MicroOS dan SLE Micro), yang sebelum ini mengetuai projek SUSE LINUX Enterprise Server selama 10 tahun, mencadangkan untuk membuang fail /var/run/utmp dalam pengedaran untuk menangani sepenuhnya masalah Y2038 dalam Glibc. Semua aplikasi yang menggunakan utmp, wtmp, dan lastlog dicadangkan untuk dipindahkan untuk mendapatkan senarai pengguna menggunakan systemd-logind.
Pada 19 Januari 2038, pembilang masa zaman yang ditentukan oleh jenis time_t 32-bit akan melimpah. Dalam Glibc, walaupun jenis time_t 64-bit diperkenalkan, untuk mengekalkan keserasian dengan aplikasi ruang pengguna 32-bit, jenis time_t 64-bit masih digunakan dalam beberapa kes pada platform 32-bit. Satu kes sedemikian ialah fail /var/run/utmp, yang menyimpan data tentang pengguna yang sedang log masuk ke sistem. Medan masa dalam utmp ditetapkan menggunakan nilai time_t 32-bit.
Hanya menukar medan dalam utmp dari semasa ke semasa daripada jenis 32-bit kepada 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 susah payah, idea untuk menggantikan panjang bit jenis time_t dalam utmp telah ditolak oleh pembangun Glibc. Atas sebab yang sama, pilihan untuk menggunakan ruang yang tersedia dalam struktur utmp untuk menambah medan masa 64-bit tambahan telah digugurkan.
Di samping itu, menukar kedalaman bit jenis dalam utmp tidak menyelesaikan masalah sedia ada lain, yang saya juga ingin singkirkan. Sebagai contoh, menulis kepada utmp memerlukan kebenaran khas, yang memerlukan keistimewaan tambahan untuk diberikan kepada proses. Masalah lain ialah seni bina utmp membolehkan pengguna tempatan melakukan serangan DoS yang memecahkan perkhidmatan utmp melalui manipulasi kunci fail, menjadikannya mustahil untuk memastikan bahawa kandungan utmp mencerminkan keadaan sebenar dalam sistem. Telah dicadangkan untuk menggunakan proses latar belakang tambahan untuk mengendalikan akses kepada utmp, tetapi untuk tugas tersebut sudah ada proses log masuk systemd dan memulakan satu lagi proses khusus tidak digalakkan (aplikasi perlu memindahkan data kepada dua pengendali pada masa yang sama) .
Pada masa yang sama, walaupun semasa menyelesaikan masalah dengan serangan DoS, kandungan utmp kekal hanya bermaklumat, tidak 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, kelakuan skrin dan tmux berbeza, dalam kes pertama setiap sesi dikira sebagai pengguna yang berasingan, dan dalam yang kedua hanya satu pengguna ditunjukkan untuk semua sesi.
Akibatnya, sebagai penyelesaian yang paling mudah, adalah dicadangkan untuk memindahkan semua aplikasi untuk menggunakan perkhidmatan log masuk systemd alternatif yang sedia ada dan, selepas tiada program sebenar yang mengakses utmp, berhenti menulis kepada utmp. Untuk menggantikan wtmp, adalah dicadangkan untuk menyediakan API untuk menulis dan membaca maklumat tentang pengguna menggunakan systemd-journald. Pangkalan kod untuk keluaran seterusnya systemd 254 sudah termasuk fungsi yang diperlukan untuk menyediakan data utmp gantian melalui libsystemd menggunakan API sd-login.h atau melalui DBUS.
Sumber: opennet.ru