Торстен Кукук (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
