sudo-rs项目在Fedora Linux系统上的兼容性改进

背景介绍

sudo-rs是一个用Rust语言实现的安全sudo替代方案，旨在提供更安全的特权升级机制。在将该项目移植到Fedora Linux系统时，开发团队发现了一些测试用例失败的问题，这些问题主要涉及系统接口兼容性和文件权限检查。

主要兼容性问题分析

1. 系统审计测试失败

项目中的secure_open_is_predictable测试用例原本设计用于验证对特定系统文件(如utmp/wtmp)的安全访问控制。这些文件通常具有特殊的所有权设置，是测试权限检查的理想候选对象。

在Fedora环境中，测试失败的原因是/var/lib/wtmp文件不存在。深入分析发现：

• utmp文件记录当前登录用户会话
• wtmp文件记录历史登录/注销信息
• 两种文件都符合测试需求(非root用户可写但不由root直接拥有)

2. 用户/组ID测试差异

测试用例test_unix_user和test_unix_group存在硬编码假设：

• 假设"daemon"用户的UID为1
• 假设"daemon"组的GID为1

然而在Fedora系统中：

• "daemon"用户实际UID为2
• "daemon"组实际GID为2

这种差异源于不同Linux发行版对系统用户/组ID分配策略的不同。

解决方案

1. 改进系统审计测试

开发团队提出了两种解决方案：

1. 寻找一个在大多数Linux发行版中都存在的、具有特定权限特征的系统文件
2. 将这部分测试迁移到合规性框架中，在测试环境中动态创建符合要求的文件

最终采用了更灵活的测试策略，避免对特定系统文件的依赖。

2. 优化用户/组测试

对于用户和组ID测试的改进方案：

• 不再硬编码特定ID值
• 改为验证ID是否在系统用户/组的标准范围内(0-1000)
• 确保查询功能能正确获取指定用户/组的ID

这种改进使测试更具可移植性，同时仍能有效验证核心功能。

技术启示

1. 可移植性设计：系统级软件开发需要考虑不同发行版的差异，避免对特定环境做出假设。

2. 测试策略：

   • 单元测试应关注核心逻辑而非具体实现细节
   • 系统级测试可以考虑使用mock或专用测试框架
   • 硬编码值应谨慎使用，特别是涉及系统配置时

3. 持续集成：将Fedora纳入CI测试环境有助于及早发现系统兼容性问题。

总结

通过对这些测试用例的改进，sudo-rs项目增强了对不同Linux发行版的兼容性，特别是Fedora系统。这一过程也体现了良好的软件开发实践：发现问题后不仅修复当前问题，更思考如何改进设计以避免类似问题再次发生。这种对可移植性和测试质量的关注，对于系统安全软件尤为重要。