1、问题背景

我们的java服务是打成war包放在tomcat容器里运行的，有一天我像往常一样去查看服务的日志文件，却提示没有权限（Permission denied）

2、问题分析

查看日志文件列表发现，9月5日之前的日志文件权限位是-rw-r--r--，而9月5日之后的日志文件权限位是-rw-r-----，tomcat进程是用root用户启的，服务生成的日志文件也就属于root用户的，而我是以普通用户登录的，由于权限位少了一个r，这也就导致我9月5日之后的日志文件没有权限查看。

为了找到问题所在，我切换到root用户身份登录。

由于linux系统文件初始的权限位与umask有关，于是我执行umask命令，输出0022，并且我尝试创建一个文件，其权限位是-rw-r--r--也对应上了呀。

为啥tomcat进程所生成的日志文件，权限位就少了一个r呢？

就在我疑惑不解时，我发现tomcat进程的启动命令行有这样一个系统属性-Dorg.apache.catalina.security.SecurityListener.UMASK=0027，如果是umask是0027的话，那一切都解释得通了.

3、深入研究

查看tomcat的catalina.sh，发现如下与umask相关的信息：

#   UMASK           (Optional) Override Tomcat's default UMASK of 0027

# Set UMASK unless it has been overridden
if [ -z "$UMASK" ]; then
    UMASK="0027"
fi
umask $UMASK

# Make the umask available when using the org.apache.catalina.security.SecurityListener
JAVA_OPTS="$JAVA_OPTS -Dorg.apache.catalina.security.SecurityListener.UMASK=`umask`"

-z用于测试字符串长度，如果为0则为真，因此如果没有设置UMASK变量则默认为0027，如果设置了则可以改变tomcat默认的umask，最后将umask作为系统属性添加到tomcat进程的启动命令行上。

不过为什么9月5日之前的权限位与9月5日之后的不一样呢？我也咨询了下公司的运维同事，是tomcat版本升级导致的，这下彻底解开谜团了，下面介绍下umask的相关知识。

4、umask

在linux系统中，umask是一种用于决定新创建文件和目录的默认权限的设置。umask定义了文件系统创建文件和目录时默认应该屏蔽掉的权限位。

4.1、umask的工作原理

umask设置了一个默认的权限掩码，这个掩码与文件系统的默认权限组合，决定了新创建文件和目录的实际权限。

默认情况下，linux文件系统的文件默认权限是644（即rw-r–r–），目录的默认权限是755（即rwxr-xr-x）。

4.2、umask的计算方式

umask值以八进制表示，每一位分别对应文件的owner、group和其他用户的权限。

umask的每一位取值范围是0到7，数值越小，实际权限越大。

新创建文件或目录的权限计算公式为：（默认权限）&（~umask值）。

4.3、示例

假设umask设置为0022：

文件的默认权限是644。应用umask后，计算新文件权限：0644 & ~0022 = 0640（即rw-r-----）。

目录的默认权限是755。应用umask后，计算新目录权限：0755 & ~0022 = 0755（即rwxr-xr-x），因为目录需要执行权限。

4.4、如何设置umask

临时设置：在当前终端会话中设置umask umask 0022

永久设置：在用户的.bashrc、.profile或/etc/profile文件中设置umask值，这样每次用户登录时都会应用这个设置。

echo "umask 0022" >> ~/.bashrc
source ~/.bashrc

全局设置：在/etc/profile或/etc/bash.bashrc中设置umask，这将影响所有用户的默认umask值。

4.5、注意事项

umask只影响新创建的文件和目录的权限，不会改变已存在文件和目录的权限。

在设置umask时，应谨慎考虑权限的安全性，避免过于宽松的权限设置。

不同的linux发行版和不同的环境可能有不同的默认umask值。

综上所述，通过合理配置umask，系统管理员可以确保文件和目录在创建时具有适当的权限，从而增强系统的安全性。