关键是要用umask 027从创建源头控制权限，使日志目录默认为750、文件为640，并配合组策略（如sgid和用户组归属）确保权限真正生效，而非依赖事后chmod。
要让新生成的应用日志目录默认具备最小化安全访问权限，关键不是“事后 chmod”，而是从创建源头控制——用 umask 配合合理用户/组模型，确保目录一落地就是 rwxr-x---（即 750）或更严格，且不向“others”开放任何权限。
为什么不能只靠 chmod？
chmod 是被动修正，而日志目录常由应用进程（如 nginx、java 服务、自研脚本）自动创建。若进程以普通用户身份运行，它会按当前 shell 或系统环境的 umask 创建目录。如果 umask 是默认的 022，新建目录就是 755（组和其他人都能进入），违反最小权限原则。哪怕你手动改一次，下次应用轮转日志或重启时又会新建一个 755 目录。
推荐配置：umask 027 + 组权限协同
设置 umask 027 是最直接有效的做法：
- 目录默认权限 777 & (~027) = 750 →
rwxr-x---（所有者全权，组可进可读，其他人完全拒绝） - 文件默认权限 666 & (~027) = 640 →
rw-r-----（日志文件无需执行，且不应被无关用户读取） - 比 022 更进一步屏蔽了 “others” 的读和执行权限，符合安全运维中“默认拒绝”要求
如何正确部署 umask 027？
必须作用于**应用实际运行的环境**，而非仅你自己的终端：
-
对 systemd 服务：在服务单元文件（
/etc/systemd/system/myapp.service）中添加：[Service]<br>UMask=0027
然后执行systemctl daemon-reload && systemctl restart myapp -
对 SysV 或手动启动脚本：在启动脚本开头显式设置：
#!/bin/bash<br>umask 0027<br># 后续执行 java -jar /opt/app.jar 等
-
对用户级守护进程（如 cron 或 screen 中运行）：修改该用户的
~/.bashrc或~/.profile，末尾加umask 0027，再用source ~/.bashrc生效
配套措施：让组权限真正可用
仅设 umask 027 不够——还要确保日志目录所属组正确，且应用进程属于该组：
- 创建专用日志组，例如：
groupadd applogs - 将应用运行用户加入该组：
usermod -aG applogs appuser - 确保日志路径父目录（如
/var/log/myapp）属组为applogs，且带 sgid 位：chown root:applogs /var/log/myapp<br>chmod g+s /var/log/myapp
这样新创建的子目录/文件自动继承applogs组，配合 umask 027，自然获得 750/640
不复杂但容易忽略：umask 必须落在应用进程的执行上下文中，且需与组策略联动，才能让“最小权限”真正落地到每个新建的日志目录上。
