[[286383]]

這是一個客戶的案例，客戶的一臺Oracle數據庫服務器突然宕機了，由于在線業務的需要，客戶沒有考慮太多就直接重啟了服務器，系統重新啟動后沒有出現問題，可是接下來，當客戶準備切換到oracle用戶下啟動數據庫時，怎么都無法進行su切換，于是問題出現了。

1、案例現象

在root用戶下，su切換到一個普通用戶oracle卻發生了錯誤，如圖1所示。

圖1  su切換發生Permission denied錯誤

于是，嘗試直接通過oracle用戶登錄系統，發現此時的oracle用戶也無法登錄了，出現與上面同樣的錯誤。

2、解決思路

從上面錯誤提示可知是權限出現了問題，那么可以從權限入手進行排查，基本思路如下：

● 用戶目錄/home/oracle權限問題。

● su程序執行權限問題。

● 程序依賴的共享庫權限問題。

● SELinux問題導致。

● 系統根空間問題。

3、排查問題

根據上面的思路，逐一檢查，考慮到su在切換到oracle用戶時會讀取oracle目錄下的環境變量配置文件，因此，首先檢查/home/oracle目錄的權限是否存在問題： 

[root@loaclhost home]# ls -al /home|grep oracle  
drwx---- 4 oralce  oinstall 4096 01-31 10:45 oracle 

從輸出可知，/home/oracle目錄的屬主是oracle用戶，而oracle用戶對這個目錄具有“rwx”權限，因此，oracle用戶目錄的權限設置是正確的，可以排除這個問題。

接著檢查su執行權限問題： 

[root@loaclhost home]# 11 /bin/su  
-rwsr-xr-x 1 root root 24120 2007-11-30 /bin/su 

可見su命令執行權限也沒有問題，這個問題也排除了。

繼續檢查su依賴的共享庫權限，使用ldd命令檢查su命令依賴的共享庫文件，如圖2所示。

圖2  通過ldd命令檢查su命令依賴的共享庫文件

根據上面的操作，依次檢查su命令依賴的每個庫文件的權限，發現也都是正常的，都具有可執行權限，因此，共享庫的問題也排除了。

根據上面的思路，繼續檢查SELinux的設置，執行命令如圖3所示。

圖3  檢查SELinux的設置

由輸出可知，SELinux處于關閉狀態，這個原因也排除了。

到目前為止，問題變得撲朔迷離，到底是哪里出現問題了呢？作為Linux運維人員，例行檢查系統根分區狀態是非常必要的，那么首先檢查一下根分區的磁盤空間大小，發現剩余空間還有很多，排除空間問題。既然報的錯誤是權限有問題，那么只要以權限為線索，不偏離這個核心就沒錯，于是繼續嘗試檢查/home目錄下各個用戶的權限，執行命令如圖4所示。

圖4  檢查/home目錄下各個用戶的權限

從輸出看每個用戶的目錄權限，都是“rwx------”，即“700”，完全沒有問題。仔細檢查思路，發現當前的目光一直停留在用戶對應的目錄上，而忽略了其他輸出信息，而問題就藏在之前沒有關注的信息中。在這個命令輸出的前兩行中，第一行權限對應的目錄是“.”，代表當前目錄，也就是/home目錄，權限為“rwxr-xr-x”，即“755”，第二行權限對應的目錄是“..”，也就是根目錄，權限卻為“rw-rw-rw-”，即“666”，此時，問題終于查找到了，原來是根目錄權限問題。

將根目錄權限設置為“rw-rw-rw-”，顯然是不正常的。在正常情況下根目錄的權限應該是“755”，為何設置成了這樣，很大的可能是誤操作。通過ls命令查看根目錄的權限時展示不是很清楚，也容易被很多運維人員忽略，其實我們可以通過另一個命令stat來詳細查看每個目錄的權限，如圖5所示。

圖5  通過stat命令查看根目錄權限

通過這個命令，可以很清晰地看到，根目錄的權限是“0666”，這才是導致su執行失敗的根本原因。

4、解決問題

知道了問題產生的原因，解決問題就非常簡單，執行如下命令： 

[root@localhost ~]# chmod 755 / 

然后就可順利執行su切換命令。

最后，做個簡單的總結，這個問題主要是由于根目錄沒有可執行權限，而Linux下所有的操作都是在根目錄下進行的，進而導致/home/oracle目錄沒有執行權限。其實根目錄權限的丟失對于系統中運行的每個用戶存在同樣的影響。因此，在權限出現問題時，一定要注意根目錄的權限。