必须先绕过selinux和systemd保护机制，再用setfacl授权；推荐改用auditd、rsyslog转发或logrotate提取日志等更安全方案。
不能直接用 setfacl 让普通用户或监控脚本读取 /var/log/secure，因为该文件受 SELinux（RHEL/CentOS/Fedora）或 systemd 的 ProtectSystem=strict 机制限制，ACL 本身会被系统策略拦截。必须先确认并绕过这些安全层，再配合 ACL 使用。
确认 SELinux 是否启用并影响访问
运行 sestatus 查看状态。若为 enabled，且上下文是 system_u:object_r:var_log_t:s0（默认），则普通进程即使有 ACL 权限也会被拒绝。
- 临时放行（仅调试）：
setenforce 0（不推荐生产环境） - 永久方案：创建自定义 SELinux 策略，允许目标用户或服务域读取
var_log_t类型文件。例如用audit2allow从 denial 日志生成策略模块 - 快速验证：用
ls -Z /var/log/secure和id -Z对比进程与文件的 SELinux 上下文
检查 systemd 服务保护机制（如使用 systemd-run 或监控服务）
若监控脚本以 systemd 服务运行（如 monitor-ssh.service），默认可能启用 ProtectSystem=full 或 ReadOnlyPaths=/var/log，导致 open() 失败，和 ACL 无关。
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 在服务单元文件中显式放宽：
ProtectSystem=false<br>ReadOnlyPaths=
或更安全地：ReadWritePaths=/var/log/secure - 重载配置：
systemctl daemon-reload && systemctl restart monitor-ssh.service
正确设置 ACL（在策略允许前提下）
确保 SELinux 和 systemd 不拦截后，再用 setfacl 授予最小权限：
- 给特定用户（如
monitor）读权限：sudo setfacl -m u:monitor:r /var/log/secure - 给某个组（如
logreaders）读权限：sudo setfacl -m g:logreaders:r /var/log/secure - 验证设置：
getfacl /var/log/secure，应看到类似user:monitor:r-- - 注意：
/var/log/secure通常属主为root:root且权限为600，ACL 不会覆盖 umask，但需确保基础权限不排斥 ACL 生效（当前 600 允许 ACL 用户访问）
更安全的替代方案（推荐）
避免直接开放敏感日志，改用审计或日志转发机制：
- 用
auditd捕获 SSH 登录事件，写入独立审计日志（如/var/log/audit/audit.log），再对那个文件设 ACL - 用
rsyslog将authpriv.*转发到专用文件（如/var/log/monitor/ssh-events.log），对该新文件赋权，不碰/var/log/secure - 用
logrotate配合 postrotate 脚本，将关键行提取并 chown/chmod 给监控用户
