O problema do ano de 2038 pode fazer com que uma parte do software falhe naquele ano. O problema afeta programas que usam a representação de tempo baseada em POSIX.
Thorsten Kukuk, líder da equipe da SUSE Future Technology (Future Technology Team, desenvolve openSUSE MicroOS e SLE Micr ), 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 do Y2038 no Glibc.
Com ele propõe-se mover todos os aplicativos que usam utmp, wtmp e lastlog para obter uma lista de usuários usando systemd-logind.
Em 19 de janeiro de 2038, os cronômetros transbordarão de período especificado pelo tipo time_t de 32 bits. No Glibc, apesar da introdução do tipo time_t de 64 bits, para manter a compatibilidade com aplicativos de espaço de usuário de 32 bits, o tipo time_t de 32 bits ainda é usado em alguns casos em plataformas de 64 bits.
Existem dois problemas principais com utmp/utmpx com glibc em, por exemplo, x86-64:
Um campo time_t de 32 bits é usado para o tempo, que transbordará em 2038
Existem problemas de design que permitem um ataque DoS (o bloqueio utmp/wtmp permite que um usuário sem privilégios negue o serviço)
Uma análise do segundo problema pelos desenvolvedores da glibc mostrou que um daemon adicional seria necessário para lidar com o acesso utmp/utmpx.Embora existam mais alguns problemas...
Um desses casos é o arquivo /var/run/utmp, que armazena dados sobre os usuários atualmente conectados ao sistema. O campo de tempo em utmp é definido usando um valor time_t de 32 bits.
É mencionado que, simplesmente alterar um campo em utmp ao longo do tempo de um tipo de 32 bits para um tipo de 64 bits não funcionará, pois isso mudará o Glibc ABI (o tipo mudará em funções como login(), getutid() e utmpname()) e quebrará a compatibilidade com aplicativos que usam utmp, incluindo w, who, uptime, login, su, sudo, useradd , systemd, sysvinit, tcsh, gerenciadores de exibição xterm, emacs, openssh, qemu, samba, rsyslog, etc.
Devido à abundância de armadilhas potenciais e diligência, os desenvolvedores de A Glibc rejeitou a ideia de substituir o tamanho do bit do tipo time_t no utmp. Pela mesma razão, a opção de usar o espaço disponível na estrutura utmp para adicionar um campo de tempo adicional de 64 bits foi removida.
Além disso, alterar a profundidade de bits do tipo em utmp não resolve outros problemas existentes, por exemplo, gravar em utmp requer permissões especiais, o que requer que os processos recebam privilégios adicionais. Outro problema é que a arquitetura utmp permite que usuários locais executem ataques DoS que quebram o serviço utmp manipulando bloqueios de arquivos, impossibilitando a certeza de que o conteúdo do utmp reflita o estado real do sistema.
Foi proposto usar um processo adicional em segundo plano para lidar com o acesso ao utmp, mas para tais tarefas já existe um processo systemd-logind e não é recomendado iniciar outro processo especializado (os aplicativos terão que transferir dados para dois controladores ao mesmo tempo).
Ao mesmo tempo, mesmo resolvendo o problema com ataques DoS, o conteúdo do utmp permanece apenas informativo, sem garantir um reflexo da realidade.
Por exemplo, diferentes emuladores de terminal e multiplexadores refletem seu estado de maneira diferente: executar cinco terminais GNOME resultará em um usuário sendo espelhado no utmp, enquanto executar cinco terminais konsole ou xterm no KDE resultará em seis. Da mesma forma, o comportamento de screen e tmux difere, 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 a solução mais simples, é proposto portar todos os aplicativos para usar o serviço systemd-logind alternativa já existente e, depois que nenhum programa real estiver acessando o utmp, pare de gravar no utmp. Para substituir o wtmp, propõe-se preparar APIs para escrever e ler informações sobre usuários usando o systemd-journald.
Finalmente, vale mencionar que a base de código para a próxima versão do systemd 254 já inclui as funções necessárias para fornecer dados utmp de substituição via libsystemd usando a API sd-login.ho via DBUS.
Se você estiver interessado em saber mais sobre isso, você pode consultar os detalhes no link a seguir.