linux新创建脚本默认无执行权限，因内核强制清零x位以防止误执行；umask仅控制r/w权限，执行权必须显式用chmod u+x赋予。
新创建的脚本文件默认没有执行权限，umask 本身无法让脚本自动获得 x 权限——这是内核强制限制，不是配置疏漏。
为什么 touch 或重定向生成的脚本永远不带 x 权限
Linux 内核在创建普通文件时会硬性清零执行位（x），无论 umask 设成 000 还是 0000，touch script.sh 得到的永远是 -rw-r--r--（即 644）。这不是 bug，而是安全设计：防止意外执行二进制垃圾或残留数据。
所以“让脚本具备基本物理安全权限”的真实目标不是靠 umask 自动加 x，而是确保：
- 脚本文件本身不被非授权用户写入（防篡改）
- 脚本所在目录不被非授权用户遍历或覆盖（防替换）
- 执行权限只在显式赋予后才存在（防误执行）
用 umask 控制脚本文件和父目录的初始读写权限
你真正能控制的是：脚本文件创建时的 r/w 权限、以及其所在目录的 r/w/x 权限。关键看场景：
- 个人开发环境（仅自己运行）：
umask 077→ 文件600，目录700，最严格 - 团队协作且需组内共享编辑：
umask 002→ 文件664，目录775，但要确认组成员已加入对应group - Web 服务部署目录（如
/var/www/scripts）：umask 027→ 文件640，目录750，适合 www-data 组+受限用户
执行 umask 027 && mkdir bin && touch bin/deploy.sh && ls -l bin/ 可验证：目录为 drwxr-x---，文件为 -rw-r----- —— 其他用户既不能读也不能进目录，物理隔离到位。
脚本执行权限必须手动添加，且应有明确意图
给脚本加执行权从来不该是“默认行为”，而应是显式动作。推荐流程：
- 先用
umask锁定基础读写安全（如umask 027） - 用
echo '#!/bin/bash' > deploy.sh创建内容 - 再用
chmod u+x deploy.sh赋予执行权 —— 这一步本身就是安全确认点 - 避免
chmod 755这类宽泛赋权；优先用chmod u+x或chmod go-w显式收窄
如果你在自动化脚本里写 umask 000 && touch a.sh && chmod +x a.sh，那 umask 000 实际毫无意义：文件权限仍是 666（无 x），chmod 才是起效环节。
永久生效时最容易忽略的加载路径问题
把 umask 027 写进 ~/.bashrc 后新开终端还是 0022？大概率是因为你用的是登录 shell（比如 SSH 登录或 GNOME 终端首次启动），它优先读 ~/.bash_profile 或 ~/.profile，而不是 ~/.bashrc。
解决方法很直接：
- 检查
~/.bash_profile是否存在，如果存在，把它加进去 - 或者在
~/.bash_profile末尾加一行：source ~/.bashrc（前提是~/.bashrc里已有umask） - 改完立刻验证：
source ~/.bash_profile && umask，别等重启终端 - 如果是
zsh用户，改的是~/.zshrc，不是~/.bashrc
复杂点在于：服务进程（如 systemd 服务、crond 任务、Web 服务器子进程）通常不走用户 shell 初始化流程，它们的 umask 由各自启动环境决定 —— 这时候得单独在服务 unit 文件里配 UMask=0027，或在脚本开头加 umask 027。这点常被忽略，却直接影响日志脚本、定时任务生成文件的安全性。
