Проблемът от 2038 г. може да доведе до повреда на част от софтуера през тази година. Проблемът засяга програми, които използват POSIX-базирано представяне на времето.
Торстен Кукук, ръководител екип от SUSE Future Technology (Future Technology Team, разработва openSUSE MicroOS и SLE Micr), който преди това е ръководил проекта SUSE LINUX Enterprise Server в продължение на 10 години, предложи да се отървете от файла /var/run/utmp в дистрибуции за пълно справяне с проблема Y2038 в Glibc.
С това предлага се преместване на всички приложения, които използват utmp, wtmp и lastlog за да получите списък с потребители, използвайки systemd-logind.
На 19 януари 2038 г. таймерите ще препълнят на определен период от 32-битов тип time_t. В Glibc, въпреки въвеждането на 64-битов тип time_t, за поддържане на съвместимост с 32-битови приложения на потребителското пространство, 32-битовият тип time_t все още се използва в някои случаи на 64-битови платформи.
Има два основни проблема с utmp/utmpx с glibc например на x86-64:
За времето се използва 32-битово поле time_t, което ще препълни при 2038
Има проблеми с дизайна, които позволяват DoS атака (блокирането на utmp/wtmp позволява на непривилегирован потребител да откаже услуга)
Анализът на втория проблем от разработчиците на glibc показа, че ще е необходим допълнителен демон за обработка на utmp/utmpx достъп.Въпреки че има още проблеми...
Един такъв случай е файлът /var/run/utmp, който съхранява данни за потребителите, свързани в момента към системата. Полето за време в utmp се задава с помощта на 32-битова стойност time_t.
Споменава се, че просто промяната на поле в utmp с течение на времето от 32-битов тип на 64-битов тип няма да работи, тъй като това ще промени Glibc ABI (типът ще се промени във функции като login(), getutid() и utmpname()) и ще наруши съвместимостта с приложения, които използват utmp, включително w, who, uptime, login, su, sudo, useradd , systemd, sysvinit, tcsh, мениджъри на дисплея xterm, emacs, openssh, qemu, samba, rsyslog и др.
Поради изобилието от потенциални клопки и трудолюбие, разработчиците на Glibc отхвърли идеята за замяна на битовата дължина на типа time_t в utmp. По същата причина е премахната опцията за използване на наличното пространство в utmp структурата за добавяне на допълнително 64-битово времево поле.
Освен това промяната на битовата дълбочина на типа в utmp не решава други съществуващи проблеми, например писането в utmp изисква специални разрешения, което изисква на процесите да бъдат предоставени допълнителни привилегии. Друг проблем е, че архитектурата на utmp позволява на локалните потребители да извършват DoS атаки, които нарушават услугата utmp чрез манипулиране на заключванията на файлове, което прави невъзможно да се гарантира, че съдържанието на utmp отразява действителното състояние на системата.
Беше предложено да се използва допълнителен фонов процес за обработка на достъпа до utmp, но за такива задачи вече има процес systemd-logind и не се препоръчва стартирането на друг специализиран процес (приложенията ще трябва да прехвърлят данни към два контролера едновременно).
В същото време, дори и при решаване на проблема с DoS атаките, съдържанието на utmp остава само информативно, без да гарантира отражение на реалността.
Например различните терминални емулатори и мултиплексори отразяват състоянието си по различен начин: стартирането на пет терминала GNOME ще доведе до дублиране на един потребител в utmp, докато стартирането на пет терминала konsole или xterm в KDE ще доведе до шест. По подобен начин поведението на screen и tmux се различава, в първия случай всяка сесия се отчита като отделен потребител, а във втория само един потребител се отразява за всички сесии.
В резултат на това, като най-простото решение, предлага се пренасяне на всички приложения за използване на услугата systemd-logind вече съществува алтернатива и след като нито една реална програма няма достъп до utmp, спрете да пишете в utmp. За да се замени wtmp, се предлага да се подготвят API за писане и четене на информация за потребители, използващи systemd-journald.
И накрая, заслужава да се спомене, че кодовата база за следващата версия на systemd 254 вече включва необходимите функции за предоставяне на заместващи utmp данни чрез libsystemd, използвайки sd-login.ho API чрез DBUS.
Ако се интересувате да научите повече за него, можете да се консултирате с подробностите В следващия линк.