Thorsten Kukuk, líder do Future Technology Team de SUSE (Future Technology Team, desenvolve openSUSE MicroOS e SLE Micro), quen dirixiu anteriormente o proxecto SUSE LINUX Enterprise Server durante 10 anos, suxeriu desfacerse do ficheiro /var/run/utmp en distribucións para resolver completamente o problema Y2038 en Glibc. Proponse que todas as aplicacións que utilicen utmp, wtmp e lastlog se movan para obter unha lista de usuarios mediante systemd-logind.
O 19 de xaneiro de 2038, os contadores de tempo especificados polo tipo time_t de 32 bits desbordaranse. En Glibc, a pesar da introdución do tipo time_t de 64 bits, para manter a compatibilidade con aplicacións de espazo de usuario de 32 bits, o tipo time_t de 64 bits aínda se usa nalgúns casos en plataformas de 32 bits. Un destes casos é o ficheiro /var/run/utmp, que almacena datos sobre os usuarios actualmente conectados ao sistema. O campo de tempo en utmp establécese mediante un valor time_t de 32 bits.
Simplemente cambiar un campo en utmp ao longo do tempo dun tipo de 32 bits a un de 64 bits non funcionará, xa que isto cambiará o ABI de Glibc (o tipo cambiará en funcións como login(), getutid() e utmpname()). e romper a compatibilidade con aplicacións que usan utmp, incluíndo w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display managers, emacs, openssh, qemu, samba, rsyslog, etc. Debido á abundancia de posibles trampas e laboriosidade, a idea de substituír a lonxitude de bits do tipo time_t en utmp foi rexeitada polos desenvolvedores de Glibc. Polo mesmo motivo, abandonouse a opción de usar o espazo dispoñible na estrutura utmp para engadir un campo de tempo adicional de 64 bits.
Ademais, cambiar a profundidade de bits do tipo en utmp non resolve outros problemas existentes, dos que tamén me gustaría desfacerme. Por exemplo, escribir en utmp require permisos especiais, o que require que se outorguen privilexios adicionais aos procesos. Outro problema é que a arquitectura utmp permite aos usuarios locais realizar ataques DoS que rompen o servizo utmp mediante a manipulación de bloqueos de ficheiros, polo que é imposible asegurarse de que o contido de utmp reflicta o estado real do sistema. Propúxose empregar un proceso de fondo adicional para xestionar o acceso a utmp, pero para este tipo de tarefas xa existe un proceso systemd-logind e non é recomendable iniciar outro proceso especializado (as aplicacións terán que transferir datos a dous controladores ao mesmo tempo) .
Ao mesmo tempo, mesmo cando se resolve o problema dos ataques DoS, o contido de utmp segue a ser só informativo, non garantindo un reflexo da realidade. Por exemplo, os distintos emuladores e multiplexores de terminais reflicten o seu estado de forma diferente: executar cinco terminais de GNOME fará que un usuario se vexa reflectido en utmp, mentres que executar cinco terminais konsole ou xterm en KDE producirá seis. Do mesmo xeito, o comportamento de screen e tmux difire, no primeiro caso cada sesión cóntase como un usuario separado, e no segundo só se reflicte un usuario para todas as sesións.
Como resultado, como solución máis sinxela, proponse transferir todas as aplicacións para utilizar o servizo alternativo systemd-logind xa existente e, despois de que non haxa programas reais que accedan a utmp, deixe de escribir en utmp. Para substituír wtmp, proponse preparar API para escribir e ler información sobre os usuarios mediante systemd-journald. O código base para a próxima versión de systemd 254 xa inclúe as funcións necesarias para proporcionar datos utmp de substitución a través de libsystemd mediante a API sd-login.h ou a través de DBUS.
Fonte: opennet.ru