Ubuntu系统默认的umask值是0022，这意味着新建文件权限为644（rw-r--r--），新建目录权限为755（rwxr-xr-x）。在生产环境和安全加固场景下，这个默认权限过于宽松——其他用户可以读取你的文件，这在多用户服务器、共享主机、容器环境中是一个实实在在的安全隐患。收紧umask到0027或0077，可以让新建文件默认变为640（rw-r-----）或600（rw-------），目录变为750（rwxr-x---）或700（rwx------），从源头上堵住权限泄露的口子。下面我会把怎么改、改哪里、改完怎么验证、以及不同场景下的最佳实践全部讲清楚。

一、umask到底是什么，为什么它决定了文件的"出生权限"

umask（user file creation mode mask）是一个权限掩码，它的作用是从系统最大权限中"减去"不需要的权限。Linux中文件最大权限是666（rw-rw-rw-），目录最大权限是777（rwxrwxrwx）。umask的计算方式是：最终权限 = 最大权限 - umask值。举个例子，umask为0022时，文件权限就是666减去022等于644，目录就是777减去022等于755。理解这个机制，你就明白了为什么umask值越大，最终权限越小、越安全。

二、Ubuntu默认umask为什么不够安全

Ubuntu桌面版和服务器版默认umask都是0022。这个值在单用户个人电脑上问题不大，但放到服务器上就有风险。具体来说：第一，新建文件其他用户可读（r--），如果服务器上有多个用户或者被入侵后攻击者以低权限用户运行，敏感配置文件、脚本、日志都可能被读取；第二，新建目录其他用户可执行和可读（r-x），意味着其他用户可以进入目录并列出文件名；第三，很多运维人员用root创建文件后切换到普通用户使用，如果umask没收紧，文件权限会继承宽松的默认值。在等保、CIS基线、等安全合规检查中，umask不小于0027是基本要求。

三、查看当前系统的umask值

在终端执行以下命令即可查看当前生效的umask：

umask

输出类似0022或0002。你也可以用更详细的方式查看：

umask -S

这会以符号形式输出，比如u=rwx,g=rx,o=rx。另外，查看/etc/login.defs文件中的UMASK配置项，以及/etc/profile、/etc/bash.bashrc、~/.bashrc、~/.profile等文件中是否有umask相关设置，这些都是umask的来源。

四、永久修改umask的具体方法

修改umask有多个层级，建议从系统全局层面统一设置，同时兼顾用户层面的覆盖。以下是四种主要方法，按推荐优先级排列。

方法一：修改/etc/login.defs（系统全局，推荐首选）

这个文件控制系统登录时的默认环境，对所有用户生效。编辑文件：

sudo vim /etc/login.defs

找到UMASK那一行，改为：

UMASK 027

保存退出。这个设置对通过login程序登录的用户生效，包括SSH登录、控制台登录等。改成027后，新建文件权限为640，目录为750。

方法二：修改/etc/profile或/etc/bash.bashrc

这两个文件对所有交互式bash shell生效。编辑/etc/profile，在文件末尾添加：

umask 027

或者编辑/etc/bash.bashrc，同样在末尾添加：

umask 027

需要注意的是，/etc/profile只对登录shell生效，/etc/bash.bashrc对所有交互式非登录shell也生效。如果你希望覆盖更全面，两个都加上也没问题，不会冲突。

方法三：修改用户级配置文件~/.bashrc或~/.profile

如果你只想针对特定用户收紧权限，编辑该用户的~/.bashrc：

vim ~/.bashrc

在末尾添加：

umask 027

然后执行source ~/.bashrc使其立即生效。这种方式适合多用户服务器上不同用户有不同安全需求的场景。

方法四：针对systemd服务单独设置

如果你的Ubuntu运行了很多systemd管理的服务（比如nginx、mysql、docker），这些服务的umask可能不受login.defs控制。需要在对应的service单元文件中设置。例如编辑nginx的service：

sudo systemctl edit nginx

在打开的编辑器中添加：

[Service]
UMask=0027

保存后执行sudo systemctl daemon-reload和sudo systemctl restart nginx。对于docker容器，可以在docker run时通过--umask参数指定，或者在Dockerfile中设置。

五、不同安全等级对应的umask推荐值

根据安全需求不同，umask的选择也不同。下面是三个常见等级：

umask 0022（默认）：文件644，目录755。适合个人桌面、开发测试环境，不适合生产服务器。

umask 0027：文件640，目录750。适合大多数生产服务器，同组用户可以读取文件但其他用户完全无法访问。这是CIS Benchmark和等保的推荐基线值。

umask 0077：文件600，目录700。适合高安全场景，比如存放密钥、证书、数据库密码文件的服务器。只有文件所有者可以访问，同组用户也被排除在外。

如果你管理的是Web服务器，建议对Web应用用户设置0027，对root和运维用户设置0077。如果是数据库服务器，直接上0077更稳妥。

六、修改后如何验证是否生效

修改完成后，重新登录或者新开一个终端，执行umask确认值已变更。然后创建测试文件和目录来验证实际权限：

touch testfile
mkdir testdir
ls -ld testfile testdir

如果umask是027，你应该看到testfile权限为-rw-r-----（640），testdir权限为drwxr-x---（750）。如果看到的是644和755，说明你改的位置不对，或者有其他配置文件覆盖了你的设置。这时候用grep命令排查：

grep -r "umask" /etc/profile /etc/bash.bashrc /etc/login.defs ~/.bashrc ~/.profile 2>/dev/null

这个命令会列出所有包含umask设置的文件，帮你找到冲突来源。

七、已有文件的权限如何批量修正

修改umask只影响新建文件，已经存在的文件权限不会自动变化。你需要手动批量修正。将所有文件改为640：

find /path/to/files -type f -exec chmod 640 {} \;

将所有目录改为750：

find /path/to/files -type d -exec chmod 750 {} \;

如果需要更激进的600/700：

find /path/to/files -type f -exec chmod 600 {} \;
find /path/to/files -type d -exec chmod 700 {} \;

注意，批量修改前一定要确认目标路径，避免误改系统关键文件导致服务异常。建议先用find命令不带chmod预览一下会影响哪些文件。

八、特殊场景的注意事项

在Ubuntu上使用sudo时，默认会保留环境变量，但有些发行版的sudo配置会重置umask。检查/etc/sudoers或/etc/sudoers.d/目录下的配置，看是否有umask相关设置。如果有Defaults umask=0022这样的行，需要一并修改。

对于SFTP/SCP场景，如果你用的是OpenSSH，sshd_config中可能有SFTPSubsystem或Subsystem配置，但umask主要还是由登录shell决定。不过如果用户通过sftp-server登录，它可能不读取~/.bashrc，这时候需要在sshd_config中用ForceCommand或在/etc/profile中确保umask被设置。

容器环境中，Docker默认umask是0000，这意味着容器内新建文件权限是666/777，非常危险。务必在Dockerfile中加入：

RUN echo "umask 027" >> /etc/profile

或者在docker run时使用--umask 0027参数。

九、umask收紧后可能遇到的问题及解决

收紧umask后最常见的问题是某些程序报权限错误。比如Web服务器的www-data用户需要读取上传目录中的文件，如果目录权限是750而www-data不在该组，就会访问失败。解决办法是将相关目录的组改为www-data所在的组，或者用ACL精细控制：

setfacl -m u:www-data:rx /var/www/uploads
setfacl -m d:u:www-data:rx /var/www/uploads

第二条是默认ACL，确保新建子文件也继承权限。另一个常见问题是crontab任务中的脚本因为文件权限不对而执行失败，检查crontab执行用户的umask并单独配置即可。

十、总结与最佳实践建议

Ubuntu安全加固中，umask收紧是成本最低、效果最直接的措施之一。不需要安装额外软件，不需要重启核心服务，改几行配置就能从文件创建源头提升安全性。我的建议是：生产服务器全局设置027，存放敏感数据的目录和用户设置077；修改后务必验证，已有文件要批量修正；同时配合ACL、属主属组管理，形成完整的权限控制体系。安全不是一个动作，而是持续的过程，umask只是其中一环，但绝对是值得第一时间落实的一环。