Thorsten Kukuk, responsable du groupe de développement des technologies du futur chez SUSE (Future Technology Team, développe openSUSE MicroOS et SLE Micro), qui a précédemment dirigé le projet SUSE LINUX Enterprise Server pendant 10 ans, a suggéré de se débarrasser du fichier /var/run/utmp. dans les distributions pour résoudre pleinement le problème 2038 dans la Glibc. Il est proposé de convertir toutes les applications utilisant utmp, wtmp et lastlog pour obtenir une liste d'utilisateurs à l'aide de systemd-logind.
Le 19 janvier 2038, les compteurs de temps d'époque spécifiés par le type time_t 32 bits déborderont. La Glibc, malgré l'introduction d'un type time_t 64 bits, continue d'utiliser un type time_t 32 bits dans certains cas sur les plates-formes 64 bits pour maintenir la compatibilité avec les applications de l'espace utilisateur 32 bits. Un tel cas est le fichier /var/run/utmp, qui stocke les données sur les utilisateurs actuellement connectés au système. Le champ d'heure dans utmp est spécifié à l'aide de la valeur time_t 32 bits.
Remplacer simplement le champ time dans utmp d'un type 32 bits à un type 64 bits ne fonctionnera pas, car cela entraînera un changement dans l'ABI de la Glibc (le type changera dans des fonctions comme login(), getutid() et utmpname ()) et rompant la compatibilité avec les applications qui utilisent utmp, notamment w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, etc. En raison de l'abondance des pièges possibles et de la complexité, l'idée de remplacer le type time_t par utmp a été rejetée par les développeurs de la Glibc. Pour la même raison, l'option d'utiliser l'espace libre disponible dans la structure utmp pour ajouter un champ temporel supplémentaire de 64 bits a été écartée.
De plus, changer la profondeur de bits du type dans utmp ne résout pas les autres problèmes existants, dont j'aimerais également me débarrasser. Par exemple, écrire dans utmp nécessite des autorisations spéciales, ce qui nécessite que les processus bénéficient de privilèges supplémentaires. Un autre problème est que l'architecture utmp permet aux utilisateurs locaux de mener des attaques DoS, entraînant une interruption du service utmp via la manipulation des verrous de fichiers, ce qui rend impossible d'être sûr que le contenu de utmp reflète l'état réel du système. Il a été proposé d'utiliser un processus d'arrière-plan supplémentaire pour gérer l'accès à utmp, mais pour de telles tâches, il existe déjà un processus systemd-logind et il n'est pas conseillé de lancer un autre processus spécialisé (les applications devront transférer des données simultanément vers deux gestionnaires).
Dans le même temps, même en résolvant le problème des attaques DoS, le contenu de utmp reste uniquement informatif et ne garantit pas le reflet de la réalité. Par exemple, différents émulateurs et multiplexeurs de terminaux reflètent leur état différemment - le lancement de cinq terminaux GNOME entraînera le reflet d'un utilisateur dans utmp, et le lancement de cinq terminaux konsole ou xterm dans KDE en entraînera six. Le comportement de screen et tmux est également différent : dans le premier cas, chaque session est comptée comme un utilisateur distinct, et dans le second, un seul utilisateur est reflété pour toutes les sessions.
En conséquence, comme solution la plus simple, il est proposé de transférer toutes les applications pour utiliser le service alternatif systemd-logind déjà existant et, une fois qu'aucun programme actuel n'accède à utmp, d'arrêter l'enregistrement sur utmp. Pour remplacer wtmp, il est proposé de préparer des interfaces logicielles pour écrire et lire des informations sur les utilisateurs utilisant systemd-journald. La base de code de la prochaine version de systemd 254 inclut déjà les fonctionnalités nécessaires pour fournir des données de remplacement utmp via libsystemd à l'aide de l'API sd-login.h ou via DBUS.
Source: opennet.ru