Торстен Кукук (Thorsten Kukuk), ръководител на екипа за развитие на технологии на бъдещето в компанията SUSE (Future Technology Team, развива openSUSE MicroOS и SLE Micro), преди това ръководил проекта SUSE LINUX Enterprise Server в продължение на 10 години, предложи да се премахне файлът /var/run/utmp в дистрибутивите, за да се реши напълно проблемът за 2038 година в Glibc. Всички приложения, използващи utmp, wtmp и lastlog, ще трябва да преминат към получаване на списък с потребители чрез systemd-logind.
На 19 януари 2038 година ще настъпи преливане на бройчетата на епохалното време, зададени от 32-битовия тип time_t. В библиотеката Glibc, въпреки че е внедрен 64-битов тип time_t, за запазване на съвместимостта с 32-битови приложения в някои случаи на 64-битови платформи продължава да се използва 32-битовият тип time_t. Един от тези случаи е файлът /var/run/utmp, който съдържа данни за потребителите, които в момента работят в системата. Полето с време в utmp се задава с използване на 32-битова стойност time_t.
Просто да се замени полето с време в utmp от 32-битов на 64-битов тип не е възможно, тъй като това ще доведе до промяна в ABI на Glibc (типът в функции като login(), getutid() и utmpname() ще се промени) и нарушение на съвместимостта с приложенията, използващи utmp, сред които w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm дисплейни мениджъри, emacs, openssh, qemu, samba, rsyslog и др. Поради многото потенциални подводни камъни и сложността на задачата, идеята за заместване на типа time_t в utmp беше отхвърлена от разработчиците на Glibc. По същата причина беше отхвърлен вариантът с използването на наличното свободно пространство в структурата 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 се предлага да се подготвят програмни интерфейси за запис и четене на информация за потребителите с помощта на systemd-journald. В кодовата база на следващото издание systemd 254 вече са включени необходимите функции за предоставяне на заместващи данни за utmp чрез libsystemd с използване на API sd-login.h или чрез DBUS.
Източник: opennet.ru
