chmod -R 600 /var/log 是危险操作，因其会破坏 rsyslog、journald、nginx 等服务写入权限，导致日志轮转失败、服务报错、SELinux 拒绝或 systemd unit 异常；日志文件权限应由服务配置（如 rsyslog 的 create 指令）或 logrotate 动态控制，而非手动递归覆盖。
不能直接递归 chmod 600 /var/log——这会破坏日志轮转、服务写入和系统审计机制，导致 rsyslog、journald 或 nginx 等服务无法写入日志，甚至触发 SELinux 报错或 systemd unit 失败。
为什么 chmod -R 600 /var/log 是危险操作
日志文件权限不是静态的，而是由多个组件协同控制：
- rsyslog 或 syslog-ng 在写入时会按配置的
create指令设置新日志文件权限（如create 640 syslog adm） - logrotate 的
create指令在轮转后重建文件时覆盖权限，你手动改的会被重置 - systemd-journald 默认不依赖 /var/log/journal 下的文件权限，而是靠
systemd-journal组控制访问 - 服务进程（如
www-data、nginx）需要对其日志目录有写权限，设成 600 后它们会报Permission denied
真正可控且安全的 root-only 日志路径：/var/log/auth.log 等认证类日志
这些文件本身设计为仅 root 可读，修改前先确认当前权限：
ls -l /var/log/auth.log /var/log/secure /var/log/faillog
若显示类似 -rw------- 1 root root，说明已是 600；若不是，用以下命令精准修复：
sudo chmod 600 /var/log/auth.log /var/log/secure /var/log/faillogsudo chown root:root /var/log/auth.log /var/log/secure /var/log/faillog- 确保 rsyslog 配置中对应规则含
create 600 root root（检查/etc/rsyslog.d/*.conf）
想让普通用户完全无法读任何 /var/log 下文件？加组比改权限更可靠
直接改权限治标不治本，且易被 logrotate 或服务重启覆盖。正确做法是控制「谁能访问」：
- 查当前用户是否在
syslog组：groups或id -nG - 若在，移出：
sudo gpasswd -d $USER syslog - 验证效果：
getent group syslog应不包含你的用户名 - 注意：Debian/Ubuntu 默认禁用
systemd-journal组访问，若用 journald，需先启用ReadKMsg=yes并加组
最常被忽略的一点：/var/log 下多数日志文件权限由服务自身或 logrotate 主动创建，而非继承父目录。强行统一设 600 不但无效，还会让 logrotate 因权限冲突跳过轮转，最终撑爆磁盘。
