系統(tǒng)版本：Linux version 4.18.0-348.el8.x86_64
前言
SELinux 是什么
安全增強(qiáng)型 Linux（SELinux）是一種采用安全架構(gòu)的 Linux? 系統(tǒng)，它能夠讓管理員更好地管控哪些人可以訪問系統(tǒng)。它最初是作為 Linux 內(nèi)核的一系列補(bǔ)丁，由美國(guó)國(guó)家安全局（NSA）利用 Linux 安全模塊（LSM）開發(fā)而成。
SELinux 工作原理
SELinux 定義了每個(gè)人對(duì)系統(tǒng)上的應(yīng)用、進(jìn)程和文件的訪問控制。利用安全策略（一組告知 SELinux 哪些能訪問，哪些不能訪問的規(guī)則）來強(qiáng)制執(zhí)行策略所允許的訪問。
當(dāng)應(yīng)用或進(jìn)程（稱為主體）發(fā)出訪問對(duì)象（如文件）的請(qǐng)求時(shí)，SELinux 會(huì)檢查訪問向量緩存（AVC），其中緩存有主體和對(duì)象的訪問權(quán)限。
開啟 SELinux 可以提升系統(tǒng)的安全性，但同時(shí)也會(huì)帶來一些問題。在特定場(chǎng)景有的人會(huì)選擇關(guān)閉 SELinux 以換取更好的兼容性。
在GreatSQL的安裝手冊(cè)里，就有關(guān)閉 SELinux 這一步。
#關(guān)閉selinux
$ setenforce 0
$ sed -i '/^SELINUX=/c'SELINUX=disabled /etc/selinux/config
不禁讓人好奇，這個(gè) SELinux 安全模塊，如果不關(guān)閉會(huì)產(chǎn)生什么問題，在使用時(shí)有哪些需要注意的地方。于是我特意嘗試了一下，開啟 SELinux 安裝 GreatSQL 數(shù)據(jù)庫(kù)，看看會(huì)出現(xiàn)哪些問題。
問題產(chǎn)生
為了發(fā)現(xiàn)問題，我特意選擇在用戶目錄（/root）下載解壓 GreatSQL 二進(jìn)制壓縮包，然后再移動(dòng)到指定目錄使用。
cd /root
wegt https://***.***/greatsql.tar.gz
tar -xvf greatsql.tar.gz
mv /root/greatsql /usr/local/
安裝過程一切順利，數(shù)據(jù)庫(kù)正常啟動(dòng)了，但是在配置 systemd 進(jìn)程守護(hù)的時(shí)候出現(xiàn)了問題。
greatsql.service文件：
vim /usr/lib/systemd/system/greatsql.service
[Unit]
Description=GreatSQL Server
After=network.target
After=syslog.target
[Install]
WantedBy=multi-user.target
[Service]
User=greatsql
Group=User=greatsql
# Have mysqld write its state to the systemd notify socket
Type=notify
# Disable service start and stop timeout logic of systemd for mysqld service.
TimeoutSec=0
# Start main service
ExecStart=/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf $MYSQLD_OPTS
# Use this to switch malloc implementation
#EnvironmentFile=-/etc/sysconfig/mysql
# Sets open_files_limit
LimitNOFILE = 10000
Restart=on-failure
RestartPreventExitStatus=1
# Set environment variable MYSQLD_PARENT_PID. This is required for restart.
Environment=MYSQLD_PARENT_PID=1
PrivateTmp=false
用 systemctl start greatsql 啟動(dòng)數(shù)據(jù)庫(kù)的時(shí)候報(bào)以下錯(cuò)誤。
[root@Linux ~]# systemctl restart greatsql
Job for greatsql.service failed because the control process exited with error code.
See "systemctl status greatsql.service" and "journalctl -xe" for details.
直接運(yùn)行mysqld?沒問題但是使用systemctl 就啟動(dòng)不了。
根據(jù)上面的報(bào)錯(cuò)，查看一下 greatsql systemd的狀態(tài)和相關(guān)日志
[root@gip Linux]# systemctl status greatsql.service
● greatsql.service
Loaded: loaded (/usr/lib/systemd/system/greatsql.service; bad; vendor preset: disabled)
Active: failed (Result: exit-code) since Tue 2023-01-10 16:00:06 CST; 17s ago
Process: 147226 ExecStart=/usr/local/greatsql/bin/mysqld --defaults-file=/etc/my.cnf $MYSQLD_OPTS (code=exited, status=203/EXEC)
Main PID: 147226 (code=exited, status=203/EXEC)
Jan 10 16:00:06 gip systemd[1]: greatsql.service: Service RestartSec=100ms expired, scheduling restart.
Jan 10 16:00:06 gip systemd[1]: greatsql.service: Scheduled restart job, restart counter is at 5.
Jan 10 16:00:06 gip systemd[1]: Stopped greatsql.service.
Jan 10 16:00:06 gip systemd[1]: greatsql.service: Start request repeated too quickly.
Jan 10 16:00:06 gip systemd[1]: greatsql.service: Failed with result 'exit-code'.
Jan 10 16:00:06 gip systemd[1]: Failed to start greatsql.service.
Jan 10 16:00:23 gip systemd[1]: /usr/lib/systemd/system/greatsql.service:1: Missing '='.
通過查看上述信息，可以得知 程序啟動(dòng)的時(shí)候拋出了報(bào)錯(cuò)。
Main PID: 147226 (code=exited, status=203/EXEC)
通過上網(wǎng)搜索可以得知，status=203/EXEC 報(bào)錯(cuò)可能和權(quán)限不足有關(guān),記一下這里的PID。
我們繼續(xù)查看一下相關(guān)日志證實(shí)一下。
[root@Linux ~]# journalctl _PID=13386
-- Logs begin at Tue 2023-01-10 16:54:11 CST, end at Tue 2023-01-10 17:09:15 CST. --
Jan 10 17:00:36 gip systemd[13386]: greatsqld.service: Failed to execute command: Permission denied
Jan 10 17:00:36 gip systemd[13386]: greatsqld.service: Failed at step EXEC spawning /usr/local/greatsql/bin/mysqld: Permission denied
可以看到確實(shí)是權(quán)限不足。
但是奇怪的事情來了，通過查看文件權(quán)限發(fā)現(xiàn)權(quán)限并沒有問題。
[root@GreatSQL bin]# ls -lah |grep mysql
-rwxr-xr-x. 1 root root 6.9M 4月 29 2022 mysql
-rwxr-xr-x. 1 root root 6.8M 4月 29 2022 mysqladmin
-rwxr-xr-x. 1 root root 7.1M 4月 29 2022 mysqlbinlog
-rwxr-xr-x. 1 root root 6.8M 4月 29 2022 mysqlcheck
-rwxr-xr-x. 1 root root 6.3K 4月 29 2022 mysqld_pre_systemd
-rwxr-xr-x. 1 root root 34K 4月 29 2022 mysqld_safe
-rwxr-xr-x. 1 root root 6.9M 4月 29 2022 mysqldump
-rwxr-xr-x. 1 root root 1.7K 4月 29 2022 mysqldumpslow
***后省略***
即便把權(quán)限改成755，甚至777 也還是會(huì)報(bào)一樣的錯(cuò)誤。
chown -R mysql:mysql /usr/local/mysql
chmod 755 -R /usr/local/mysql
問題原因
后面我有檢查了所有相關(guān)文件的權(quán)限，都沒問題，但是程序還是會(huì)報(bào)權(quán)限不足。
在網(wǎng)上翻閱了資料，發(fā)現(xiàn)了問題產(chǎn)生原因。
是SELinux 的問題， 因?yàn)槲业亩M(jìn)制文件是先下載到 /root? 目錄，然后才移到 /usr/local/greatsql?目錄，從/root?目錄移動(dòng)到/usr/local/目錄時(shí)它們的 SELinux 上下文不會(huì)自動(dòng)變更，依然是用戶主目錄。所以出現(xiàn)了權(quán)限問題。
解決方法：
#恢復(fù)文件的安全上下文
restorecon -rv /usr/local/greatsql
總結(jié)
可執(zhí)行文件是先存放在用戶目錄，然后移動(dòng)到別的目錄，文件的 SELinux 上下文不會(huì)自動(dòng)變更，依然是用戶目錄。
這就導(dǎo)致了,能直接運(yùn)行，但是通過 systemd 啟動(dòng)時(shí)仍然報(bào) Permission denied權(quán)限不足的問題。
解決方法就是用restorecon命令用來恢復(fù)SELinux文件屬性
restorecon -rv 目標(biāo)目錄
相關(guān)鏈接：
解決文件權(quán)限正確，但 systemd 服務(wù)仍然提示沒有權(quán)限，啟動(dòng)失敗。(https://blog.csdn.net/kunyus/article/details/106592236)
一文帶你看懂 SELinux 是什么? (redhat.com(https://www.redhat.com/zh/topics/linux/what-is-selinux)
