服务用户使用keyctl读取用户密钥提示Permission denied问题排查

执行以下命令时，最后一步出现权限拒绝错误：

$ sudo -u backup_agent keyctl add user LUKS_PASSWORD "your-secure-password" @u
1013632990
$ sudo -u backup_agent keyctl list @u
1 key in keyring:
1013632990: --alswrv   110   110 user: LUKS_PASSWORD
$ sudo -u backup_agent keyctl read 1013632990
keyctl_read_alloc: Permission denied

需求是为服务用户backup_agent创建密钥，供其cron任务中的脚本使用，以下是具体排查思路：

• 检查密钥的详细权限信息
  从keyctl list输出的权限位--alswrv来看，r代表读取权限，但可能存在显示与实际权限不匹配的情况。执行keyctl show 1013632990查看更完整的权限细节，确认是否真的拥有读取权限。

• 验证用户环境的完整性
  sudo -u切换用户时可能未完全加载目标用户的环境变量，比如与密钥环相关的XDG_RUNTIME_DIR等。尝试用sudo -i -u backup_agent进入目标用户的交互式shell后再执行keyctl read命令，排查是否因环境变量缺失导致问题——毕竟cron任务的环境比交互式shell更受限，提前在完整环境中测试能快速定位问题。

• 检查PAM配置对密钥环的影响
  部分系统的PAM配置会限制非交互式会话（如cron）的密钥环访问。查看/etc/pam.d/sudo和/etc/pam.d/cron的配置，确认是否存在pam_keyinit.so相关项，是否在切换用户或执行cron任务时正确初始化了密钥环。若cron任务未初始化密钥环，可能无法访问之前添加的密钥。

• 确认密钥归属的密钥环
  @u代表用户私有密钥环，但sudo -u添加密钥时，可能误将密钥添加到当前用户的密钥环而非目标用户的。切换到backup_agent后执行keyctl show @u，确认密钥确实存在于该用户的密钥环中。也可以尝试直接指定目标用户的密钥环路径，比如keyctl add user LUKS_PASSWORD "your-secure-password" /run/user/110/keyring（110是backup_agent的UID，从keyctl list输出中获取），明确指定密钥存储位置。

• 排查安全模块限制
  若系统启用了SELinux或AppArmor，可能会阻止keyctl的读取操作。临时关闭SELinux（执行setenforce 0）测试是否能读取，若恢复正常，查看/var/log/audit/audit.log找出具体限制规则，再调整SELinux策略。对于AppArmor，检查相关profile是否允许keyctl的读取动作。

• 模拟cron任务环境测试
  写一个简单的测试脚本：

  #!/bin/bash
  echo "当前用户: $(whoami)"
  echo "密钥列表: $(keyctl list @u)"
  keyctl read 1013632990 2>&1
  

  为backup_agent用户添加cron任务执行该脚本，查看输出日志，确认cron环境下是否能识别密钥，以及具体错误信息——这能直接模拟实际使用场景的问题。

内容的提问来源于stack exchange，提问作者psandor