Y2038：用 logind 替换 utmp

简介

在最近的更新中，openSUSE MicroOS、Tumbleweed 和变体中的许多软件包已从 utmp 切换到 systemd-logind。

Y2038

为什么我们需要 utmp 的替代方案？utmp 不是很老且被广泛接受吗？

在 UTC 时间 2038 年 1 月 19 日 03:14:07，32 位 time_t 计数器将会溢出。到目前为止，普遍的说法是，在具有 64 位 time_t 的 64 位系统上，您在 Y2038 问题方面是安全的。但 glibc 为了与 32 位用户空间应用程序兼容，即使在 64 位系统上，在某些地方也使用 32 位 time_t。这适用于 wtmp 使用的 struct utmp。

在 glibc 中将 struct utmp 更改为使用 64 位 time_t 非常复杂，并且在所有情况下都与 ABI 不兼容，此外磁盘上的格式也会发生不兼容的更改。出于这些原因，glibc 开发者计划在未来某个时候弃用该 API。

除了 Y2038 问题之外，utmp API 还有其他几个问题

• 存在设计问题，允许 DoS 攻击 utmp/wtmp locking allows non-privileged user to deny service
• 由于固定格式，用户名和设备名称的长度限制为 32 个字符，而如今所有其他工具都允许更长甚至无限的名称。并且字符串除非使用变量的全部长度，否则以空字符结尾。这使得数据解析复杂化，并导致应用程序时不时出现错误。
• 使用方式，尤其是应该创建哪个条目，没有明确定义。因此：如果您使用 GNOME 并启动 5 个终端 (gnome-terminal)，/usr/bin/who 将报告一个用户。如果您使用 KDE 或 xdm 并启动 5 个终端 (konsole 或 xterm)，/usr/bin/who 将报告六个用户。如果您使用 screen 或 tmux，则相同：使用 screen，/usr/bin/who 将报告每个会话一个额外的用户，使用 tmux 您只会看到一个用户。因此，您只能将数据用于信息目的，而不能将其信任用于监控或其他类似用途。

在评估了多种不同的替代方案后，决定使用 systemd-logind

• systemd-logind 始终在运行
• 有一个中央工具控制着什么是会话，什么不是
• 使用 libsystemd 的 API 不受 utmp API 问题的困扰

这对用户意味着什么？

希望：什么也没有

所有大型项目都接受了我们的补丁或编写了他们自己的支持，并且其中大多数已经发布了新版本。例如，coreutils、procps、shadow、util-linux 和 systemd 本身。使用 who、w 或类似工具应该会为您提供与之前相似的输出，但有一个很大的区别：您将不再在输出中看到 xterm、konsole、screen 或类似的会话。

展望

为了兼容性，/run/utmp 将继续创建，直到大多数软件包都已调整。预计在 systemd v255（包含无需 utmp 即可进行广播消息的必要补丁）之后，/run/utmp 将不再创建。

• 仍缺少一些软件包
  • qemu：补丁正在进行中
  • samba：补丁存在并经过测试，缺少集成
  • net-snmp：SR 待处理
  • rsyslog：SR 待处理

演示

• All Systems Go! 的录制
• OSS Europe 2023