CentOS服务器安全之设置umask值限制文件默认权限

umask值在Linux系统中直接决定了新建文件或目录的默认权限。很多运维人员安装完CentOS后，从未主动检查过这个值，导致服务器上每天产生大量权限为644或755的文件。这意味着同组的其他用户，甚至服务器上所有的普通账户，都能读取你的配置文件、日志甚至包含敏感信息的脚本。这不是一个潜在的漏洞，而是一个已经敞开的门。解决这个问题的唯一办法，就是主动设置严格的umask值，从源头掐断权限滥用的可能。

umask不是直接赋予权限，而是一张权限屏蔽表。系统在创建文件时，会先用最大权限减去umask值，得到最终的默认权限。文件的最大权限是666，也就是所有者和组以及其他人都可读写。目录的最大权限是777，多了执行权限。假如你设置了umask为022，那么新建文件的权限就是666减去022，等于644。新建目录的权限是777减去022，等于755。这个减法不是简单的数学减法，而是按位进行的逻辑运算。具体来说，是将umask的值取反，再与最大权限做逻辑与运算。

举个例子，umask设置为027。文件的初始权限666，用数字表示就是rw-rw-rw-。027代表----w-rwx。取反后变成rwxr-x---。两者做与运算，结果是rw-r-----，也就是640。这意味着文件所有者可以读写，同组用户可以读，其他用户没有任何权限。目录的初始权限777，运算后结果是rwxr-x---，也就是750。所有者可以读写执行，同组可以读和执行，其他用户无任何权限。这个计算过程看似复杂，但你只需要记住几个常用的umask值和对应的最终权限即可。

CentOS系统中有多个地方可以设置umask，它们的优先级和生效范围完全不同。最底层是系统全局设置，通常在/etc/profile或者/etc/bashrc文件中。这两个文件分别对应用户登录shell和非登录shell。CentOS 7及之后的版本，系统级的umask默认值通常写在/etc/login.defs文件中，但这个文件只影响通过useradd创建的用户，不影响root用户。你可以在/etc/profile文件末尾看到类似umask 022这样的配置，这是大多数CentOS发行版的出厂设置。

用户级别的umask设置优先级高于系统全局。每个用户的家目录下都有.bashrc和.bash_profile文件，你可以在这两个文件中单独设置umask值。当用户登录时，.bash_profile会被执行，而每次打开新的shell终端，.bashrc都会被执行。如果你在这两个文件中都设置了umask，最后执行的那个会覆盖之前的设置。还有一个容易忽略的地方是/etc/sudoers文件。通过sudo执行命令时，umask值可能被sudo的默认配置重置。你可以用visudo命令查看并修改Defaults umask_override参数，确保通过sudo创建的文件也遵循你设定的umask。

服务进程的umask设置更加隐蔽。systemd管理的服务，可以在单元文件中用UMask指令单独设置。比如你有一个Java应用，它的启动脚本可能不会读取用户的.bashrc文件，而是直接继承systemd的默认umask。CentOS 7及之后版本，systemd的默认umask是0022。这意味着所有通过systemd启动的服务，创建的文件权限都是644。如果你的应用会生成包含数据库密码的配置文件，644的权限意味着服务器上任何一个普通用户都能读取。你需要在具体的service文件中添加UMask=0027，强制服务进程使用更严格的权限屏蔽。

共享开发环境中，多人共用一台服务器，代码文件需要在同一项目组内共享。这时umask设置为002比较合理，新建文件权限664，目录权限775。项目组成员可以互相编辑文件，但其他组的成员无法访问。前提是你已经通过用户组做好了权限隔离，每个项目组有独立的用户组。如果开发环境没有严格的组划分，建议直接使用022，至少保证文件对其他用户不可写。

生产服务器应该使用更严格的umask值。Web应用的代码文件，通常只需要运行Web服务的用户有读取权限。你可以将umask设置为027，这样新建文件权限为640，目录权限为750。Web服务用户和文件所有者同组，可以正常读取文件，其他用户完全无法访问。对于更敏感的场景，比如存放私钥、证书或包含密码的配置文件，建议将umask设置为077。新建文件权限600，目录权限700。只有文件所有者能访问，同组和其他用户都没有任何权限。这种设置可以防止Web应用被漏洞利用后，攻击者读取其他用户的敏感文件。

FTP服务器或文件共享服务器需要特别注意umask设置。vsftpd服务有独立的local_umask和anon_umask参数，分别控制本地用户和匿名用户上传文件的权限。Pure-FTPd使用Umask指令。这些服务的umask设置独立于系统全局配置，你需要单独检查。如果FTP用户上传的文件需要让Web服务读取，可以将local_umask设置为022，这样上传的文件权限是644。如果只允许上传者自己管理文件，设置为077更安全。

你需要先摸清当前系统的真实umask值。以root用户登录后，直接输入umask命令，会显示当前的屏蔽值。再切换到普通用户，同样执行umask命令。如果两个值不同，说明用户级别覆盖了系统设置。接着用su - username的方式切换用户，这会模拟完整的登录过程，读取.bash_profile文件。如果这个值又不一样，说明登录shell和非登录shell的umask配置不同。你还需要检查正在运行的服务进程的umask值。找到进程的PID，比如nginx的PID是12345，执行cat /proc/12345/status | grep Umask，就能看到这个进程实际使用的umask。这个值可能与你在shell中看到的不同，因为服务进程可能由systemd启动，继承的是systemd的umask。

检查历史遗留文件的权限同样重要。在关键目录下执行find命令，可以找出权限过于宽松的文件。比如在/etc目录下查找所有其他用户可读的文件，执行find /etc -type f -perm -o+r。这个命令会列出所有权限中包含其他用户可读的文件。你可能会惊讶地发现，很多配置文件都是644权限，包括某些包含敏感信息的文件。对于Web应用的根目录，执行find /var/www -type f -perm -o+r，检查是否有文件对其他用户开放了读取权限。如果Web应用以独立用户运行，这些文件完全不需要对其他用户开放。

修改系统全局umask，编辑/etc/profile文件。在文件末尾添加一行umask 027。这个设置会影响所有通过登录shell登录的用户。对于非登录shell，编辑/etc/bashrc文件，同样在末尾添加umask 027。如果你想让某个用户使用不同的umask值，编辑该用户家目录下的.bashrc文件，添加umask 077。修改完成后，用户需要重新登录或者执行source ~/.bashrc让配置生效。对于通过useradd新建的用户，编辑/etc/login.defs文件，找到UMASK这一行，将默认的022改为027。这样以后新建的用户，默认umask就是027。

systemd服务的umask修改需要单独处理。假设你有一个名为myapp的服务，编辑/etc/systemd/system/myapp.service文件，在[Service]段落中添加UMask=0027。然后执行systemctl daemon-reload重载配置，再执行systemctl restart myapp重启服务。验证服务进程的umask是否生效，用前面提到的查看进程status文件的方法。如果你使用supervisord管理进程，在supervisord.conf的[supervisord]段落中添加umask=027，重启supervisord服务后，所有子进程都会继承这个umask。

对于FTP服务，vsftpd的配置文件在/etc/vsftpd/vsftpd.conf。添加或修改local_umask=027，anon_umask=077。前者控制本地用户上传文件的权限，后者控制匿名用户。Pure-FTPd的配置文件在/etc/pure-ftpd/pure-ftpd.conf，找到Umask这一行，修改为Umask 117:007。这个格式比较特殊，第一个数字用于文件，第二个用于目录。117表示文件权限为660，007表示目录权限为770。修改后重启FTP服务即可生效。

修改umask后，你需要验证是否真正生效。创建一个测试文件touch /tmp/test_file，然后执行ls -l /tmp/test_file查看权限。如果umask设置为027，你应该看到权限为-rw-r-----。创建一个测试目录mkdir /tmp/test_dir，权限应该是drwxr-x---。在不同用户下重复这个测试，确保所有场景都符合预期。对于服务进程，你可以让应用生成一个临时文件，或者查看应用日志文件的新建日志，确认权限是否正确。

长期监控文件权限变化同样重要。你可以编写一个简单的脚本，定期扫描关键目录，检查是否有权限异常的文件。脚本内容大致如下：

#!/bin/bash
# 检查/etc目录下其他用户可读的文件
find /etc -type f -perm -o+r -exec ls -l {} \; > /tmp/perm_check.log
# 检查Web目录下其他用户可读的文件
find /var/www -type f -perm -o+r -exec ls -l {} \; >> /tmp/perm_check.log
# 如果日志不为空，发送告警
if [ -s /tmp/perm_check.log ]; then
    mail -s "权限异常告警" admin@example.com < /tmp/perm_check.log
fi

将这个脚本加入crontab，每天执行一次。如果发现权限异常的文件，立即排查是哪个进程或用户创建的，以及为什么没有遵循系统umask设置。有些应用可能会在代码中显式调用chmod函数，强制修改文件权限，这种情况需要修改应用代码或配置。

很多人以为umask设置为000能让文件创建后权限最大，方便使用。这在生产环境中极其危险。000的umask意味着新建文件权限666，目录权限777。任何用户都能修改和删除你的文件。即使你后来用chmod修改了权限，在文件创建到权限修改之间，存在一个时间窗口，攻击者可以利用这个窗口读取或篡改文件。正确的做法是始终使用严格的umask，只在必要时用chmod临时放宽权限。

另一个误区是认为umask只影响shell中创建的文件。实际上，任何进程创建文件时都会受到umask的影响，包括数据库进程、Web服务器进程、编译工具等。MySQL的数据文件、PostgreSQL的数据目录、Redis的dump文件，它们的权限都由启动这些服务的用户umask决定。如果你发现数据库文件权限是644，说明启动数据库的用户umask是022，这会让服务器上其他用户都能读取数据库文件。修改数据库服务启动用户的umask，或者在systemd服务文件中添加UMask指令，才能从源头解决这个问题。

还有人认为设置了严格的umask后，就可以高枕无忧。umask只能控制新建文件的默认权限，对已经存在的文件没有影响。你需要配合使用chmod和chown命令，修复历史遗留文件的权限。另外，umask不能阻止用户主动执行chmod 777命令。如果你需要更细粒度的权限控制，应该考虑使用ACL访问控制列表，或者SELinux的强制访问控制。umask是基础防线，不是唯一的防线。

在多用户共享的服务器上，umask设置不当会导致严重的安全问题。假设Web应用以www用户运行，你的个人账户和www用户同组。如果umask是002，你新建的脚本文件权限是775，www用户不仅能读取，还能执行。如果脚本中包含数据库密码，www用户就能获取这些密码。即使你后来修改了文件权限，在文件刚创建的那一刻，密码已经暴露了。将umask设置为077，新建文件权限700，就能完全避免这种横向移动的风险。

最后，umask的设置需要与整体的安全策略配合。如果你的服务器启用了SELinux，文件上下文会提供额外的保护层。但SELinux不能替代基本的文件权限管理。umask解决的是自主访问控制层面的问题，SELinux解决的是强制访问控制层面的问题。两者配合使用，才能构建纵深防御体系。不要因为启用了SELinux就忽视umask设置，也不要因为设置了严格的umask就关闭SELinux。