MySQL文件及目錄權限設置分析-愛可生

1

背景

創建文件及目錄時，我們會對相關的權限有一定的要求，默認的可以通過系統的umask來控制。然而，在我們使用MySQL時，無論是開始使用前的初始化，還是MySQL實例啟動後，創建的相關文件及目錄，並不受umask控制，MySQL 默認創建出來的文件權限是0660，目錄權限是0700，並且，在通過引入MySQL初始化相關的環境變量解決了這一問題後，在以不同的MySQL的啟動方式啟動實例後，創建的文件及目錄的權限也不相同。以下，將從幾個方面分別討論。

2

umask對系統文件及

目錄的影響

以下是linux man-page中對umask的相關描述：

從該描述中，可以看出，umask影響open、mkdir等其他系統調用產生的新的文件或目錄的權限。

2.1 umask對open函數的影響

open函數用到umask的相關形式為：

截取open函數的部分描述：

通過該段描述，當沒有默認的acl時，創建的文件的權限應為mode & ~umask，而一般情況下針對文件來說，系統默認的mode為0666(並不是所有的文件都可以執行)，所以實際創建的文件權限應為 0666 & ~umask，當umask為0022時，創建出來的文件的權限應為0644。

2.2 umask對mkdir函數的影響

mkdir函數用的umask的相關形式：

截取相關描述：

在沒有默認acl的情況下，創建的目錄的權限為 mode & ~umask & 0777，一般情況下，目錄的默認的mode為0777，所以實際創建的目錄權限應為 0777 & ~umask & 0777，當umask為0022時，創建的目錄的權限應為0755。

2.3 參考資料

• [umask 參考](http://man7.org/linux/man-pages/man2/umask.2.html)
• [open 參考](http://man7.org/linux/man-pages/man2/open.2.html)
• [mkdir 參考](http://man7.org/linux/man-pages/man2/mkdir.2.html)

3

Umask對MySQL默認的影響

3.1 Umask對MySQL默認的影響

當umask=0022時，初始化後生成的文件及目錄權限：

可以看出創建出來的文件的權限為0660，目錄權限為0700,與系統umask並無關係。

實例啟動後，通過mysql連接數據庫，創建新的數據庫及表，查看權限：

新創建的文件及目錄權限為0660、0700，同樣與umask無關。

3.2 源碼層面分析

通過這段源碼可以看出，當沒有設置UMASK、UMASK_DIR環境變量時，MySQL默認創建文件及目錄的權限分別為0660、0700。

4

自定義MySQL相關文件及

目錄權限

4.1 初始化過程中文件及目錄的權限

4.1.1 方法

MySQL 提供另外一種方法，設置UMASK和UMASK_DIR環境變量，可以影響創建文件和目錄的權限：

The default UMASK and UMASK_DIR values are 0660 and 0700, respectively. MySQL assumes that the value forUMASK or UMASK_DIR is in octal if it starts with a zero. For example,setting UMASK=0600 is equivalent toUMASK=384 because 0600 octal is 384 decimal.

The UMASK and UMASK_DIR variables, despite their names, are used as modes, not masks:

If UMASK is set, mysqld uses ($UMASK | 0600) as the mode for file creation, so that newly created files have a mode in the range from 0600 to 0666 (all values octal).

If UMASK_DIR is set, mysqld uses (\$UMASK_DIR | 0700) as the base mode for directory creation, which then is AND-ed with ~(~$UMASK & 0666), so that newly created directories have a mode in the range from 0700 to 0777 (all values octal). The AND operation may remove read and write permissions from the directory mode, but not execute permissions.

簡單的把核心內容翻譯一下，設置了UMASK及UMASK_DIR之後，生成的文件及目錄的權限應分別為：

如設置了UMASK=0664，UMASK_DIR=0774，在經過以上運算之後，生成的文件及目錄的權限應為0664,0774。

4.1.2 設置方式

設置這兩個環境變量的建議做法是，在用戶的/etc/skel/{bashrc, bash_profile} 文件和root用戶的.bashrc .bash_profile中加入：

4.1.3 驗證

驗證所用版本：mysql 5.6.31

系統umask：

UMASK、UMASK_DIR環境變量：

初始化後生成的文件及目錄權限為：

4.1.4 特殊的目錄權限

在初始化完成後，mysql、test文件夾的權限和預期不符，出現此種情況的原因為mysql、test文件夾的創建是通過scripts/mysql_install_db這個perl腳本實現的，找到相關的代碼如下，可以看出，這兩個文件夾的創建時的權限是固定的。

4.2 啟動及MySQL實例運行中創建文件及目錄的權限

啟動mysql 有兩種方式，/etc/init.d/mysql start 或 service mysql start，這兩種方式都能夠正確的啟動MySQL，但實際情況是有差別的，尤其是在設置了上述環境變量的情況下。

查看了service 命令的 manual，描述是這樣的：

DESCRIPTION
service runs a System V init>

通過驗證後確實如此，用service 命令啟動 會去掉UMASK環境變量：

4.2.1 驗證

啟動後，生成的mysql.err文件權限為0640，通過mysql連接數據庫，創建的新的database及table，查看權限：

實例運行後創建的文件及目錄權限為0660、0700，UMASK、UMASK_DIR環境變量未起作用。

4.2.1.1 源碼層面分析

使用service mysql start 啟動：

使用service mysql start 啟動不會產生 atoi_octal 函數調用，所以UMASK、UMASK_DIR環境變量沒有生效。

4.2.2 解決辦法

1. 啟動腳本中加入 export UMASK等環境變量；
2. 不使用service命令啟動。

驗證

驗證所用版本：mysql 5.6.31

以下，通過在每次啟動MySQL服務之前，刪除MySQL的錯誤日誌，啟動之後查看生成的錯誤日誌的權限來具體說明這個問題(本例中，錯誤日誌為mysql.err)，最初初始化生成的錯誤日誌的權限為0664，即 rw-rw-r–。

啟動腳本中加入 export UMASK等環境變量：

啟動後mysql.err權限為0664，通過mysql連接數據庫，創建新的數據庫及表，查看權限：

新創建的文件及數據庫目錄的權限為0664、0774。

4.2.2.1 源碼層面分析

使用service啟動：

產生atoi_octal調用，UMASK、UMASK_DIR環境變量生效。

1. 不使用service命令啟動

啟動後生成的mysql.err權限仍為0664，通過mysql連接數據庫，創建新的數據庫及表，查看權限：

新創建的文件及數據庫目錄的權限為0664、0774。

4.2.2.2 源碼層面分析

使用/etc/init.d/mysql 啟動：

使用/etc/init.d/mysql start 啟動，產生atoi_octal函數調用，UMASK、UMASK_DIR環境變量生效。

4.2.3 特殊文件的權限

socket文件權限：

每次MySQL啟動之後產生的socket文件(本例中的mysql.sock)的權限與預期不符，通過查看相關源碼，以及相關socket文件生成的源碼，可以解釋該現象。

4.2.3.1 源碼層面分析

MySQL socket文件生成源碼：

socket文件生成的相關源碼：

4.3 總結

1. 代碼中單獨定義了my_umask變量，並通過判斷環境變量來調整my_umask的值；
2. 如果日誌文件存在, 重啟時打開日誌時並不會對文件權限變更；如果文件不存在，打開日誌時會創建並設定文件權限。