Thorsten Kukuk, lãnh đạo Nhóm Công nghệ Tương lai tại SUSE (Nhóm Công nghệ Tương lai, phát triển openSUSE MicroOS và SLE Micro), người trước đây đã lãnh đạo dự án SUSE LINUX Enterprise Server trong 10 năm, đã đề xuất loại bỏ tệp /var/run/utmp trong phân phối để giải quyết đầy đủ vấn đề Y2038 trong Glibc. Tất cả các ứng dụng sử dụng utmp, wtmp và lastlog được đề xuất chuyển sang nhận danh sách người dùng sử dụng systemd-logind.
Vào ngày 19 tháng 2038 năm 32, bộ đếm thời gian kỷ nguyên được chỉ định bởi loại time_t 64 bit sẽ bị tràn. Trong Glibc, mặc dù đã giới thiệu loại time_t 32 bit, nhưng để duy trì khả năng tương thích với các ứng dụng không gian người dùng 64 bit, loại time_t 32 bit vẫn được sử dụng trong một số trường hợp trên nền tảng 32 bit. Một trong những trường hợp như vậy là tệp /var/run/utmp, lưu trữ dữ liệu về những người dùng hiện đang đăng nhập vào hệ thống. Trường thời gian trong utmp được đặt bằng giá trị time_t XNUMX bit.
Chỉ thay đổi một trường trong utmp từ loại 32-bit sang loại 64-bit theo thời gian sẽ không hoạt động, vì điều này sẽ thay đổi Glibc ABI (loại sẽ thay đổi trong các chức năng như login(), getutid() và utmpname() ) và phá vỡ khả năng tương thích với các ứng dụng sử dụng utmp, bao gồm w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, trình quản lý hiển thị xterm, emacs, openssh, qemu, samba, rsyslog, v.v. Do có rất nhiều cạm bẫy có thể xảy ra và tốn nhiều công sức, ý tưởng thay thế độ dài bit của loại time_t trong utmp đã bị các nhà phát triển Glibc từ chối. Vì lý do tương tự, tùy chọn sử dụng không gian có sẵn trong cấu trúc utmp để thêm trường thời gian 64 bit bổ sung đã bị loại bỏ.
Ngoài ra, việc thay đổi độ sâu bit của loại trong utmp không giải quyết được các vấn đề hiện có khác mà tôi cũng muốn loại bỏ. Ví dụ: ghi vào utmp yêu cầu các quyền đặc biệt, yêu cầu các đặc quyền bổ sung được cấp cho các quy trình. Một vấn đề khác là kiến trúc utmp cho phép người dùng cục bộ thực hiện các cuộc tấn công DoS phá vỡ dịch vụ utmp thông qua thao tác khóa tệp, khiến không thể chắc chắn rằng nội dung của utmp phản ánh trạng thái thực trong hệ thống. Người ta đã đề xuất sử dụng một quy trình nền bổ sung để xử lý quyền truy cập vào utmp, nhưng đối với các tác vụ như vậy, đã có quy trình đăng nhập hệ thống và không nên bắt đầu một quy trình chuyên biệt khác (các ứng dụng sẽ phải chuyển dữ liệu sang hai trình xử lý cùng một lúc) .
Đồng thời, ngay cả khi giải quyết được vấn đề tấn công DoS, nội dung của utmp vẫn chỉ mang tính thông tin, không đảm bảo phản ánh đúng thực tế. Ví dụ: các bộ mô phỏng và bộ ghép kênh thiết bị đầu cuối khác nhau phản ánh trạng thái của chúng khác nhau - chạy năm thiết bị đầu cuối GNOME sẽ dẫn đến một người dùng được phản ánh trong utmp, trong khi chạy năm thiết bị đầu cuối konsole hoặc xterm trong KDE sẽ dẫn đến sáu thiết bị đầu cuối. Tương tự, hành vi của màn hình và tmux khác nhau, trong trường hợp đầu tiên, mỗi phiên được tính là một người dùng riêng biệt và trong trường hợp thứ hai, chỉ một người dùng được phản ánh cho tất cả các phiên.
Do đó, giải pháp đơn giản nhất là đề xuất chuyển tất cả các ứng dụng sang sử dụng dịch vụ đăng nhập hệ thống thay thế hiện có và sau khi không có chương trình thực tế nào truy cập utmp, hãy ngừng ghi vào utmp. Để thay thế wtmp, đề xuất chuẩn bị các API để viết và đọc thông tin về người dùng bằng systemd-journald. Cơ sở mã cho bản phát hành tiếp theo của systemd 254 đã bao gồm các chức năng cần thiết để cung cấp dữ liệu utmp thay thế qua libsystemd bằng API sd-login.h hoặc qua DBUS.
Nguồn: opennet.ru