logrotate 的 create 指令必须同时指定权限、属主和属组，缺一不可；仅写权限值（如 create 0640）会失效，导致日志文件沿用不安全的默认权限。
create 指令必须显式声明权限和属主，不能只写 mode
logrotate 的 create 不是 chmod 命令，它必须一次性指定「权限 + 所有者 + 所属组」三个字段，缺一不可。只写 create 640 或 create 0600 会报错或静默失效——新日志文件将沿用原文件的权限（可能为 644），导致敏感日志被普通用户读取。
常见错误现象：logrotate -d /etc/logrotate.conf 调试时提示 error: error setting owner and/or group of /var/log/app.log: Operation not permitted，往往是因为 create 后少写了用户和组。
-
create 0600 apache apache：正确，权限 0600，属主 apache，属组 apache -
create 640 root adm：正确，权限 640，属主 root，属组 adm（注意：不加前导零也合法，但建议统一用 0640 风格） -
create 0640：错误，缺少 owner 和 group，logrotate 忽略该行 -
create 0640 nginx：错误，只有两个参数，logrotate 认为 group 缺失，报错退出
权限值选 0600 还是 0640？看服务运行身份和访问需求
权限设置不是越严越好，得匹配实际使用场景。核心原则是：让日志写入进程能写、运维人员能读、其他用户完全不能碰。
- 若服务以非 root 用户运行（如
nginx、apache、appuser），且运维人员不属该用户组 → 用create 0600 <owner><owner></owner></owner>，例如create 0600 nginx nginx - 若运维人员已加入
adm组，且服务由root启动（如 rsyslog、某些 PHP-FPM 配置）→ 用create 0640 root adm，既保安全又支持组内读取 - 绝对避免
create 0644或create 0755：这会让其他用户（others）获得读或执行权限，审计时直接算高危项
为什么不能依赖 umask 或全局 create？
/etc/logrotate.conf 里如果写了全局 create（比如 create 0640 root root），它会对所有后续配置生效，极易误伤——比如把 /var/log/apt/history.log 也设成 root root，导致 apt 日志无法被普通用户查看（尽管这通常不敏感，但破坏了默认行为）。
更危险的是，某些服务配置（如 /etc/logrotate.d/httpd）若没写 create，就会继承全局设置，而它的日志可能本该由 apache 用户写入，权限不匹配会导致写入失败或服务崩溃。
- 最佳实践：每个服务专属配置（
/etc/logrotate.d/xxx）中独立写create，不依赖全局 - 禁用全局
create，除非你明确控制所有日志路径且确认无冲突 - 用
logrotate -d测试时重点检查 “creating new log file” 行是否显示预期的 uid/gid 和 mode
测试 create 是否生效的三步验证法
改完配置别急着等 cron，手动触发并验证最可靠。
- 先用调试模式看逻辑：
logrotate -d /etc/logrotate.d/myapp，确认输出里有类似creating new log file /var/log/myapp/app.log mode = 0600 uid = 48 gid = 48 - 再强制轮转一次：
logrotate -f /etc/logrotate.d/myapp - 最后检查结果：
ls -l /var/log/myapp/app.log，确认权限、属主、属组与create声明完全一致；同时确认服务仍在正常写日志（tail -f观察是否有新内容）
最容易被忽略的是：有些服务（如旧版 Apache）在 postrotate 里用 kill -USR1 通知重开日志，但如果 create 权限不对，新文件创建失败，USR1 之后反而会写入失败或回退到临时文件——所以权限验证必须结合服务行为一起看。
