非oracle用户sqlplus,非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。保持其在安装时候的要求。