logrotate 的 create 参数直接指定文件权限和归属，完全绕过 umask 机制；语法为 create mode owner:group（如 0644 www-data:www-data），mode 必须是八进制，且需显式声明用户和组。
logrotate 的 create 参数不依赖也不覆盖系统全局 umask，它是独立、显式地定义新日志文件的权限和归属。换句话说：create 是硬编码权限，完全绕过 umask 机制。这不是“覆盖”，而是“替代”——它直接调用 open() 系统调用时传入指定 mode（如 0644），内核据此创建文件，根本不会参考当前 shell 或进程的 umask 值。
所以，你不需要、也不能在 logrotate 配置里“配置 umask 来影响 create”。正确做法是：直接在 create 行写死你需要的权限和用户组，确保与应用运行身份严格匹配。
create 参数必须显式声明权限和归属
create 的语法为：
create mode owner:group
或（兼容旧版本）：
create mode owner group
-
mode是八进制数字（如0644），不是 umask，它表示最终文件权限（例如0644→-rw-r--r--） -
owner:group明确指定属主和属组，避免依赖当前执行用户（通常是 root）
✅ 正确示例（Nginx 日志）：
/var/log/nginx/*.log {
daily
missingok
rotate 30
compress
delaycompress
create 0644 www-data:www-data
sharedscripts
postrotate
if [ -f /var/run/nginx.pid ]; then
kill -USR1 `cat /var/run/nginx.pid`
fi
endscript
}⚠️ 错误写法（以为能“继承 umask”）：
create 644 www-data:www-data # 缺少前导 0，会被解释为十进制 644 → 权限混乱 create 0644 # 没有 owner:group → 新文件归 root:root，应用可能无权写入
为什么不能靠全局 umask 控制 logrotate 创建的文件？
-
logrotate默认以 root 身份运行（通过 cron），其子进程调用open()时传入的是create指定的 mode，不受 shellumask影响； - 即使你在
/etc/login.defs或 PAM 中设了umask 0077，它只对交互式登录或 PAM 启动的 shell 生效，对logrotate这类由 cron 直接 fork 的服务进程无效； - 更关键的是：
logrotate创建日志文件的时机，是在轮转后、应用尚未重新打开文件前。若权限/归属错，应用（如rsyslog、nginx）会因“Permission denied”静默失败，日志中断却无报错。
生产环境安全实践建议
-
权限最小化：
- 普通服务日志 →
create 0640 user:group（如0640 nginx:adm） - 审计类日志（如
auditd）→create 0640 root:audit，再配合 ACL 或组权限控制读取范围 - 密钥/凭证相关日志（极少见，但需警惕）→
create 0600 root:root
- 普通服务日志 →
避免
missingok+create组合陷阱：
若日志路径不存在或被误删，missingok会让logrotate跳过整个轮转流程，包括create步骤 → 新文件不会生成 → 应用持续写入失败。
✅ 替代方案：用notifempty（空日志不轮转）+ 确保路径存在（可通过prerotate脚本mkdir -p）-
软链接要特别处理：
如果日志路径是软链（如/var/log/app/current.log → /var/log/app/20260721.log），logrotate默认操作目标文件，而非链接本身。需加：copytruncate # 截断原文件，保持链接指向不变 # 或 copy # 复制内容并重命名，再清空原文件（更安全，但需应用支持重开）
验证是否生效？别只看 umask
改完配置后，强制执行一次并检查实际文件：
sudo logrotate -f /etc/logrotate.d/your-config ls -l /var/log/your-app.log
应看到类似：
-rw-r----- 1 youruser yourgroup 1234 Jul 21 09:00 /var/log/your-app.log
而不是 -rw-rw-rw- 或归属 root:root。
不复杂但容易忽略
