Thorsten Kukuk, líder do grupo de desenvolvimento de tecnologias futuras na SUSE (Future Technology Team, que desenvolve openSUSE MicroOS e SLE Micro), que antes liderou o projeto SUSE LINUX Enterprise Server por 10 anos, sugeriu eliminar o arquivo /var/run/utmp nas distribuições como uma solução completa para o problema do ano 2038 no Glibc. Todos os aplicativos que utilizam utmp, wtmp e lastlog devem ser adaptados para obter a lista de usuários por meio do systemd-logind.
Em 19 de janeiro de 2038, ocorrerá um estouro dos contadores de tempo epoch definidos pelo tipo de 32 bits time_t. Na biblioteca Glibc, apesar da introdução do tipo de 64 bits time_t, por razões de compatibilidade com aplicativos de 32 bits, em alguns casos nas plataformas de 64 bits, o tipo time_t de 32 bits ainda é utilizado no espaço do usuário. Um desses casos é o arquivo /var/run/utmp, que armazena dados dos usuários atualmente ativos no sistema. O campo de tempo no utmp é definido usando um valor de 32 bits time_t.
Simplesmente substituir o campo de tempo no utmp de 32 bits para um tipo de 64 bits não é viável, pois isso levaria a uma alteração no ABI do Glibc (o tipo nas funções, como login(), getutid() e utmpname() seria modificado) e à quebra de compatibilidade com aplicativos que utilizam 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 possíveis armadilhas e à complexidade, a ideia de substituir o tipo time_t no utmp foi rejeitada pelos desenvolvedores do Glibc. Pela mesma razão, a opção de usar o espaço livre na estrutura do utmp para adicionar um campo de 64 bits adicional de tempo foi descartada.
Além disso, alterar a largura de tipo em utmp não resolve outros problemas existentes, dos quais também gostaríamos de nos livrar. Por exemplo, para gravar em utmp, são necessários privilégios especiais, o que requer a concessão de permissões adicionais aos processos. Outro problema está relacionado ao fato de que a arquitetura utmp permite que usuários locais realizem ataques DoS, levando à interrupção do serviço utmp através de manipulações com bloqueios de arquivos, tornando impossível garantir que o conteúdo de utmp reflete o estado real do sistema. Foi sugerido usar um processo em segundo plano adicional para gerenciar o acesso ao utmp, mas para tais tarefas já existe o processo systemd-logind, e iniciar mais um processo especializado não é viável (as aplicações teriam que enviar dados simultaneamente para dois manipuladores).
Mesmo ao resolver o problema de ataques DoS, o conteúdo de utmp permanece apenas informativo, não garantindo a reflexão da realidade. Por exemplo, diferentes emuladores e multiplexadores de terminais refletem seu estado de maneiras distintas — iniciar cinco terminais GNOME resultará na reflexão de um único usuário em utmp, enquanto iniciar cinco terminais konsole ou xterm no KDE resultará em seis. O mesmo se aplica ao comportamento do screen e tmux; no primeiro caso, cada sessão é contada como um usuário separado, enquanto no segundo reflete apenas um usuário para todas as sessões.
Assim, como a solução mais simples, sugere-se migrar todos os aplicativos para o uso do serviço alternativo já existente, o systemd-logind, e depois que não houver mais programas relevantes acessando utmp, interromper a gravação em utmp. Para substituir o wtmp, sugere-se preparar interfaces de programação para gravação e leitura de informações sobre usuários utilizando systemd-journald. As funções necessárias para fornecer dados substitutivos de utmp através da libsystemd com o uso da API sd-login.h ou via DBUS já estão incluídas na base de código da próxima versão do systemd 254.
Fonte: opennet.ru
