非oracle使用者無法運作sqlplus

今天收到一個case，客戶說我們打完PSU之後，他們的sqlplus就無法使用了，報錯為：

somemachine_abc $ sqlplus

ld.so.1: sqlplus: fatal: /opt/app/oracle/product/11.1.0/db_1/lib/libclntsh.so.11.1: Permission denied

Killed

檢查該lib檔案的權限：

somemachine_abc $ ls -l /opt/app/oracle/product/11.1.0/db_1/lib/libclntsh.so.11.1

-rwxr-x--- 1 oracle dba 54380032 Jul 16 02:04 /opt/app/oracle/product/11.1.0/db_1/lib/libclntsh.so.11.1

發現該檔案的權限是對于other是0。非oracle使用者沒有這個檔案的權限。

進一步對比這個檔案的更改時間和PSU的時間：

somemachine_abc:SUCM01P1:/opt/app/oracle/product/11.1.0/db_1/OPatch>./opatch lsinventory

Invoking OPatch 11.2.0.1.5

Oracle Interim Patch Installer version 11.2.0.1.5

Copyright (c) 2010, Oracle Corporation. All rights reserved.

Oracle Home : /opt/app/oracle/product/11.1.0/db_1

Central Inventory : /opt/app/oracle/product/oraInventory

from : /var/opt/oracle/oraInst.loc

OPatch version : 11.2.0.1.5

OUI version : 11.1.0.7.0

OUI location : /opt/app/oracle/product/11.1.0/db_1/oui

Log file location : /opt/app/oracle/product/11.1.0/db_1/cfgtoollogs/opatch/opatch2011-07-27_18-47-43PM.log

Patch history file: /opt/app/oracle/product/11.1.0/db_1/cfgtoollogs/opatch/opatch_history.txt

Lsinventory Output file location : /opt/app/oracle/product/11.1.0/db_1/cfgtoollogs/opatch/lsinv/lsinventory2011-07-27_18-47-43PM.txt

--------------------------------------------------------------------------------

Installed Top-level Products (2):

Oracle Database 11g 11.1.0.6.0

Oracle Database 11g Patch Set 1 11.1.0.7.0

There are 2 products installed in this Oracle Home.

Interim patches (2) :

Patch 11724936 : applied on Sat Jul 16 02:05:52 EST 2011

Unique Patch ID: 13654261

Created on 11 Apr 2011, 05:19:26 hrs PST8PDT

Bugs fixed:

9068088, 7207654, 8865718, 7835247, 7648406, 9054253, 6851110, 7206858

9744252, 7497788, 9956713, 8251486, 6434104, 8851675, 7502237, 8211920

9352179, 7013124, 7643188, 7135702, 7529174, 7196532, 8300793, 7705669

7119382, 9001453, 7424804, 7408621, 7426336, 8856696, 6843972, 10264680

8437213, 8836375, 8216875, 7527650, 7454752, 8290478, 9499302, 7412296

6805009, 8318050, 7185113, 7639602, 8539335, 9711859, 9011088, 7131291

9109536, 8199266, 9114072, 8230457, 7420394, 8914979, 9713537, 8876094

……

我們看到PSU的時間确實和這個檔案的更改時間是吻合的。

開了SR給oracle，oracle在實驗環境中重做了該PSU，發現2個問題：

（1）資料庫版本是11.1的，應該是11.1的opatch，而不是我們用的11.2.

（2）即使是用11.1或11.2的opatch打，檔案的權限也是不會改的。

那麼為什麼這個檔案的權限會更改？是手工更改的？

後續有别的故障發生，已經有好幾個資料庫，也是打完PSU之後，非oracle的使用者無法執行sqlplus了，但是在打PSU的過程中，沒有人去手工改過那個檔案的權限，patch的log也是顯示成功。這是怎麼回事？

随着進一步的調查，發現上述資料庫的oracle使用者，在.profile中，umask由于安全的原因，在前段時間都已經被改成027，而不是安裝時，oracle文檔要求的022。這樣，當進行patch時候，該lib檔案會被删除，在重新生成一個，在重新生成的時候，按照027的權限，就變成了other為0的權限了。

somemachine_abc::/opt/app/oracle/admin>cat .profile |grep umask

umask 027

結論：不要輕易更改oracle使用者的umask。保持其在安裝時候的要求。

原文位址：http://www.oracleblog.org/working-case/can-not-run-sqlplus-as-non-oracle-account/