Rsyslog与SFTP日志记录中的Unix套接字创建问题分析

问题背景

在Linux系统中，管理员经常需要为chroot环境下的SFTP用户配置详细的日志记录。传统做法是通过rsyslog服务接收来自OpenSSH的internal-sftp子系统的日志消息，这通常需要创建一个Unix域套接字作为日志传输通道。

问题现象

在Oracle Linux 8.9和RHEL 9.3系统中，当rsyslog升级到特定版本(8.2102.0-15.el8及更高)后，系统管理员发现rsyslog无法在chroot目录下创建所需的Unix套接字，错误提示为"Read-only file system"。有趣的是，回退到早期版本(8.2102.0-13.el8)后问题消失。

技术分析

权限模型变化

rsyslog服务启动时以root身份运行，但随后会降低权限以syslog用户身份运行。新版本可能在权限降低时机上有所调整，导致在创建套接字时已不具备root权限。

SELinux因素

在RHEL 9.3等启用了SELinux的系统上，还观察到SELinux阻止rsyslogd对套接字文件执行setattr操作的情况。这表明新版本可能在文件属性设置方面有更严格的要求。

文件系统挂载特性

SFTP的chroot环境通常需要将/dev目录以只读方式挂载，而rsyslog需要在该目录下创建可写的日志套接字，这种矛盾在rsyslog新版本中可能被更严格地检查。

解决方案

临时解决方案

1. 回退rsyslog到已知可用的旧版本
2. 手动预创建套接字文件并设置适当权限

长期解决方案

1. AppArmor/SELinux策略调整：

   • 对于Ubuntu系统，修改/etc/apparmor.d/usr.sbin.rsyslogd
   • 添加针对日志文件和套接字的读写权限规则

2. 目录权限优化：

   mkdir /var/log/sftp
   chown syslog:adm /var/log/sftp
   

3. 配置调整：

   • 考虑将日志套接字移至chroot环境外部的可写位置
   • 使用bind mount将外部套接字映射到chroot环境内

最佳实践建议

1. 在生产环境升级前，应在测试环境验证rsyslog的日志功能
2. 对于关键日志服务，考虑采用独立的日志收集方案而非依赖系统日志服务
3. 定期检查日志轮转功能是否正常工作
4. 在容器化环境中，应特别注意日志套接字的挂载方式

总结

rsyslog新版本对Unix套接字的创建和权限管理更加严格，这反映了现代Linux系统对安全性的重视。系统管理员需要理解这种变化背后的安全考量，并通过适当的配置调整来平衡功能需求与安全要求。对于SFTP日志记录这种特殊场景，可能需要结合多种技术手段才能实现既安全又可靠的日志收集方案。