Thorsten Kukuk, líder do grupo de desenvolvimento de tecnologia futura da SUSE (Future Technology Team, desenvolve openSUSE MicroOS e SLE Micro), que anteriormente liderou o projeto SUSE LINUX Enterprise Server por 10 anos, sugeriu se livrar do arquivo /var/run/utmp em distribuições para resolver completamente o problema de 2038 no Glibc. Propõe-se que todos os aplicativos que usam utmp, wtmp e lastlog sejam convertidos para obter uma lista de usuários usando systemd-logind.
Em 19 de janeiro de 2038, os contadores de tempo de época especificados pelo tipo time_t de 32 bits serão estourados. Glibc, apesar de introduzir um tipo time_t de 64 bits, continua a usar um tipo time_t de 32 bits em alguns casos em plataformas de 64 bits para manter a compatibilidade com aplicativos de espaço do usuário de 32 bits. Um desses casos é o arquivo /var/run/utmp, que armazena dados sobre usuários atualmente logados no sistema. O campo de hora em utmp é especificado usando um valor time_t de 32 bits.
Simplesmente substituir o campo de tempo em utmp de um tipo de 32 bits para um tipo de 64 bits não funcionará, pois isso levará a uma mudança na Glibc ABI (o tipo mudará em funções como login(), getutid() e utmpname ()) e quebrando a compatibilidade com aplicativos que usam utmp, incluindo w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm display manager, emacs, openssh, qemu, samba, rsyslog, etc. Devido à abundância de possíveis armadilhas e complexidade, a ideia de substituir o tipo time_t em utmp foi rejeitada pelos desenvolvedores do Glibc. Pelo mesmo motivo, foi descartada a opção de utilizar o espaço livre disponível na estrutura utmp para adicionar um campo de hora adicional de 64 bits.
Além disso, alterar a profundidade de bits do tipo em utmp não resolve outros problemas existentes, dos quais eu também gostaria de me livrar. Por exemplo, escrever para utmp requer direitos especiais, o que exige que os processos recebam privilégios adicionais. Outro problema é que a arquitetura utmp permite que usuários locais realizem ataques DoS, levando à interrupção do serviço utmp através da manipulação de bloqueios de arquivos, o que torna impossível ter certeza de que o conteúdo do utmp reflete o estado real do sistema. Foi proposto usar um processo de segundo plano adicional para lidar com o acesso ao utmp, mas para tais tarefas já existe um processo systemd-logind e não é aconselhável iniciar outro processo especializado (os aplicativos terão que transferir dados para dois manipuladores simultaneamente).
Ao mesmo tempo, mesmo ao resolver o problema dos ataques DoS, o conteúdo do utmp permanece apenas informativo e não garante um reflexo da realidade. Por exemplo, diferentes emuladores e multiplexadores de terminal refletem seu estado de maneira diferente - lançar cinco terminais GNOME resultará em um usuário sendo refletido no utmp, e lançar cinco terminais konsole ou xterm no KDE resultará em seis. O comportamento de screen e tmux é igualmente diferente: no primeiro caso, cada sessão é contada como um usuário separado e, no segundo, apenas um usuário é refletido para todas as sessões.
Como resultado, como solução mais simples, propõe-se transferir todos os aplicativos para usar o serviço alternativo systemd-logind já existente e, quando não houver programas atuais acessando o utmp, interromper a gravação no utmp. Para substituir o wtmp, propõe-se preparar interfaces de software para escrever e ler informações sobre usuários usando o systemd-journald. A base de código para a próxima versão do systemd 254 já inclui a funcionalidade necessária para fornecer dados de substituição utmp via libsystemd usando a API sd-login.h ou via DBUS.
Fonte: opennet.ru