Thorsten Kukuk, responsable de l'équipe de développement des technologies futures chez SUSE, a proposé de supprimer le fichier /var/run/utmp dans les distributions pour résoudre complètement le problème de l'année 2038 dans Glibc. Tous les applications utilisant utmp, wtmp et lastlog devraient être adaptées pour obtenir la liste des utilisateurs via systemd-logind.
Le 19 janvier 2038, il y aura un débordement des compteurs de temps épocal, définis par le type 32 bits time_t. Dans la bibliothèque Glibc, malgré l'introduction du type time_t 64 bits pour maintenir la compatibilité avec les applications 32 bits, l'espace utilisateur continue dans certains cas d'utiliser le type time_t 32 bits même sur des plateformes 64 bits. L'un de ces cas est le fichier /var/run/utmp, qui stocke les données des utilisateurs actuellement actifs dans le système. Le champ de temps dans utmp est défini en utilisant une valeur time_t 32 bits.
Remplacer simplement le champ de temps dans utmp de 32 bits à 64 bits n'est pas possible, car cela provoquerait un changement d'ABI dans Glibc (le type changerait dans des fonctions comme login(), getutid() et utmpname()) et violerait la compatibilité avec les applications utilisant utmp, parmi lesquelles w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, les gestionnaires d'affichage xterm, emacs, openssh, qemu, samba, rsyslog, etc. En raison des nombreux pièges potentiels et de la complexité, l'idée de remplacer la taille du type time_t dans utmp a été rejetée par les développeurs de Glibc. Pour la même raison, l'option d'utiliser l'espace libre existant dans la structure utmp pour ajouter un champ de temps 64 bits supplémentaire a également été abandonnée.
En outre, le changement de la taille du type dans utmp ne résout pas les autres problèmes existants que nous aimerions également éliminer. Par exemple, l'enregistrement dans utmp nécessite des droits spéciaux, ce qui implique de donner des privilèges supplémentaires aux processus. Un autre problème est que l'architecture d'utmp permet aux utilisateurs locaux d'effectuer des attaques DoS, entraînant des perturbations du service utmp en manipulant les verrous sur le fichier, ce qui rend incertain le fait que le contenu de utmp reflète l'état réel du système. Pour gérer l'accès à utmp, il a été proposé d'utiliser un processus en arrière-plan supplémentaire, mais pour de telles tâches, un processus systemd-logind existe déjà, et le démarrage d'un autre processus spécialisé n'est pas judicieux (les applications devront transmettre des données à deux gestionnaires simultanément).
Cependant, même en résolvant le problème des attaques DoS, le contenu d'utmp reste uniquement informatif, ne garantissant pas le reflet de la réalité. Par exemple, différents émulateurs et multiplexeurs de terminaux reflètent leur état de manière différente : le lancement de cinq terminaux GNOME entraînera un affichage dans utmp d'un seul utilisateur, tandis que le lancement de cinq terminaux konsole ou xterm dans KDE affichera six. Le comportement de screen et tmux diffère également, dans le premier cas chaque session est comptée comme un utilisateur distinct, tandis que dans le second, un seul utilisateur est affiché pour toutes les sessions.
En fin de compte, la solution la plus simple proposée est de migrer toutes les applications vers l'utilisation du service alternatif existant systemd-logind, et une fois que tous les programmes en cours d'utilisation d'utmp seront obsolètes, de cesser l'enregistrement dans utmp. Pour remplacer wtmp, il est proposé de préparer des interfaces logicielles pour écrire et lire des informations sur les utilisateurs à l'aide de systemd-journald. Les fonctions nécessaires pour fournir des données de remplacement pour utmp via libsystemd en utilisant l'API sd-login.h ou via DBUS ont déjà été incluses dans la base de code de la prochaine version de systemd 254.
Source : opennet.ru
