umask 通过按位取反后与默认权限（文件666、目录777）做与运算来屏蔽权限，而非直接设置；Linux内核禁止普通文件默认有执行权限，与umask无关。
umask 是怎么“减掉”权限的
umask 不是直接设置权限，而是从默认权限里“屏蔽”掉某些位。文件默认最大权限是 666（rw-rw-rw-），目录是 777（rwxrwxrwx）。umask 值按位取反后与默认值做与运算（& ~umask），这才是真实创建时的权限。
比如 umask 0022：
- 文件：666 & ~0022 = 644 → -rw-r--r--
- 目录：777 & ~0022 = 755 → drwxr-xr-x
注意：Linux 禁止新创建的普通文件带执行权限，哪怕 umask 是 0000，touch 出来的文件也绝不会自动有 x 位 —— 这是内核级安全限制，和 umask 无关。
临时改 umask 的常见误操作
很多人在终端里输 umask 0077 后立刻 touch test，发现权限是 -rw-------，就以为生效了。但容易忽略三点：
- 这个设置只对当前 shell 进程有效，新开终端、SSH 登录、脚本子 shell 都不继承
- 如果用了
sudo -i或su -，会加载目标用户的配置，覆盖当前 umask - 某些 IDE 或编辑器（如 VS Code Remote）启动的终端可能绕过你的
.bashrc，导致 umask 没被重设
验证是否真生效，别只看 umask 输出值，一定要用 touch + ls -l 实测：
umask 0077 touch afile && mkdir adir ls -l afile adir
永久设置该写进哪个配置文件
用户级永久生效，优先写入 ~/.bashrc；但要注意 Shell 类型：
Hive从0.10版本(包含0.10版本)以后可以通过元数据来控制权限，Hive-0.10之前的版本对权限的控制主要是通过Linux的用户和用户组来控制，不能对Hive表的CREATE、SELECT、DROP等操作进行控制，当然Hive基于元数据来控制权限也不是完全安全的，目的就是为了防止用户不小心做了不该做的操作。感兴趣的朋友可以过来看看
-
bash用户：写~/.bashrc（交互式非登录 shell 默认读它） -
zsh用户：得写~/.zshrc，写错文件就白配了 - 登录 shell（如 SSH）可能先读
~/.profile，而它默认不 source.bashrc，所以单独加一行source ~/.bashrc更稳妥
系统级统一策略（如服务器多用户环境），应改 /etc/pam.d/common-session 并加 session optional pam_umask.so umask=0027，而不是动 /etc/profile —— 后者对非 bash shell 或图形界面登录可能无效。
为什么 umask 002 和 0007 的效果看起来一样
初学者常困惑：umask 002 和 umask 0007 都让组和其他人没写权限，但实际行为不同：
-
umask 002：文件 →664（-rw-rw-r--），目录 →775（drwxrwxr-x） -
umask 0007：文件 →660（-rw-rw----），目录 →770（drwxrwx---）
区别在于“其他人（others）”有没有读权限。协作项目中若用 0007，其他用户连 ls 都看不到你的文件 —— 这不是权限太严，而是设计意图错位：umask 控制的是“新建时的起点”，不是事后 ACL 策略。真要精细控制，该用 setgid 目录 + 组管理，而不是靠 umask 把门焊死。
