Le problème de l'année 2038 pourrait entraîner la défaillance d'une partie du logiciel cette année-là. Le problème affecte les programmes qui utilisent la représentation du temps basée sur POSIX.
Thorsten Kukuk, chef d'équipe de SUSE Future Technology (Future Technology Team, développe openSUSE MicroOS et SLE Micr ), qui a précédemment dirigé le projet SUSE LINUX Enterprise Server pendant 10 ans, suggéré de se débarrasser du fichier /var/run/utmp dans les distributions pour résoudre complètement le problème Y2038 dans Glibc.
Avec lui il est proposé de déplacer toutes les applications qui utilisent utmp, wtmp et lastlog pour obtenir une liste des utilisateurs utilisant systemd-logind.
Le 19 janvier 2038, les minuteurs déborderont de la période spécifiée par le type time_t 32 bits. Dans Glibc, malgré l'introduction du type time_t 64 bits, pour maintenir la compatibilité avec les applications d'espace utilisateur 32 bits, le type time_t 32 bits est toujours utilisé dans certains cas sur les plates-formes 64 bits.
Il y a deux problèmes principaux avec utmp/utmpx avec glibc sur par exemple x86-64 :
Un champ time_t de 32 bits est utilisé pour l'heure, qui débordera à 2038
Il existe des problèmes de conception qui permettent une attaque DoS (le blocage utmp/wtmp permet à un utilisateur non privilégié de refuser le service)
Une analyse du deuxième problème par les développeurs de la glibc a montré qu'un démon supplémentaire serait nécessaire pour gérer l'accès utmp/utmpx.Même s'il y a d'autres problèmes...
Un tel cas est le fichier /var/run/utmp, qui stocke des données sur les utilisateurs actuellement connectés au système. Le champ de temps dans utmp est défini à l'aide d'une valeur time_t de 32 bits.
Il est mentionné que, changer simplement un champ en utmp au fil du temps d'un type 32 bits à un type 64 bits ne fonctionnera pas, car cela changera l'ABI Glibc (le type changera dans des fonctions comme login(), getutid() et utmpname()) et rompra la compatibilité avec les applications qui utilisent utmp, y compris w, who, uptime, login, su, sudo, useradd , systemd, sysvinit, tcsh, gestionnaires d'affichage xterm, emacs, openssh, qemu, samba, rsyslog, etc.
En raison de l'abondance des pièges potentiels et de l'assiduité, les développeurs de Glibc a rejeté l'idée de remplacer la longueur en bits du type time_t dans utmp. Pour la même raison, l'option d'utiliser l'espace disponible dans la structure utmp pour ajouter un champ de temps supplémentaire de 64 bits a été supprimée.
De plus, la modification de la profondeur de bits du type dans utmp ne résout pas les autres problèmes existants, par exemple, l'écriture dans utmp nécessite des autorisations spéciales, ce qui nécessite d'accorder des privilèges supplémentaires aux processus. Un autre problème est que l'architecture utmp permet aux utilisateurs locaux d'effectuer des attaques DoS qui cassent le service utmp en manipulant les 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 recommandé de démarrer un autre processus spécialisé (les applications devront transférer des données vers deux contrôleurs en même temps).
Dans le même temps, même en résolvant le problème avec les attaques DoS, le contenu d'utmp reste uniquement informatif, sans garantir le reflet de la réalité.
Par exemple, différents émulateurs de terminaux et multiplexeurs reflètent leur état différemment : l'exécution de cinq terminaux GNOME entraînera la mise en miroir d'un utilisateur dans utmp, tandis que l'exécution de cinq terminaux konsole ou xterm dans KDE en entraînera six. De même, le comportement de screen et tmux diffère, 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 porter toutes les applications pour utiliser le service systemd-logind alternative déjà existante et, après qu'aucun programme réel n'accède à utmp, arrêtez d'écrire sur utmp. Pour remplacer wtmp, il est proposé de préparer des API pour écrire et lire des informations sur les utilisateurs utilisant systemd-journald.
Enfin, il convient de mentionner que la base de code de la prochaine version de systemd 254 inclut déjà les fonctions nécessaires pour fournir des données utmp de remplacement via libsystemd en utilisant l'API sd-login.ho via DBUS.
Si vous souhaitez en savoir plus, vous pouvez consulter les détails dans le lien suivant.