关于从 16 位 UID 更改为 32 位 UID 的说明

作者:

Chris Wing <wingc@umich.edu>

最后更新时间:

2000 年 1 月 11 日

• 内核代码在 ioctl 或数据结构中在用户和内核空间之间通信时，必须考虑 __kernel_uid_t 和 __kernel_uid32_t。

• 内核代码应在内核私有结构和代码中使用 uid_t 和 gid_t。

在所有 Linux 架构上为 32 位 UID 还需要完成的工作

• 磁盘配额有一个有趣的限制，它与最大 UID/GID 无关。它们受基础文件系统上的最大文件大小限制，因为配额记录写入与相关 UID 对应的偏移量。需要进一步调查以查看配额系统是否可以正确处理巨大的 UID。如果它可以在所有架构上处理 64 位文件偏移量，则这应该不是问题。

• 决定是否保持与系统帐户文件的向后兼容性，或者是否应该像注释建议的那样破坏它（目前，旧的 16 位 UID 和 GID 仍然写入磁盘，并且先前填充空间的一部分用于存储单独的 32 位 UID 和 GID）

• 需要验证 OS 仿真是否调用 16 位 UID 兼容系统调用（如果被仿真的操作系统使用了 16 位 UID），或者是否正确使用了 32 位 UID 系统调用。

  这至少会影响

  • Intel 上的 iBCS

  • sparc64 上的 sparc32 仿真（需要支持添加到 sparc32 的任何新的 32 位 UID 系统调用）

• 验证所有文件系统是否行为正确。

  目前，32 位 UID _应该_适用于

  • ext2

  • ufs

  • isofs

  • nfs

  • coda

  • udf

  Ioctl() 修复已完成

  • ncpfs

  • smbfs

  具有简单修复以防止 16 位 UID 回绕的文件系统

  • minix

  • sysv

  • qnx4

  尚未检查其他文件系统。

• ncpfs 和 smpfs 文件系统目前无法在所有 ioctl() 中使用 32 位 UID。已添加了一些具有 32 位 UID 的新 ioctl()，但还需要更多。（以及新的用户<->内核数据结构）

• ELF 核心转储格式仅在 arm、i386、m68k、sh 和 sparc32 上支持 16 位 UID。修复此问题可能不是那么重要，但需要添加一个新的 ELF 部分。

• 用于控制内核 NFS 服务器的 ioctl() 仅在 arm、i386、m68k、sh 和 sparc32 上支持 16 位 UID。

• 确保 AX25 网络的 UID 映射功能正常工作（它应该是安全的，因为它总是使用 32 位整数在用户和内核之间通信）