LIBCLNTSH.SO: WRONG ELF CLASS: ELFCLASS32错误一例

某套数据库以dba组用户登录正常,但以非dba组用户登录时出现LIBCLNTSH.SO: WRONG ELF CLASS: ELFCLASS32错误,如下例子:


su  - maclean

sqlplus 

ld.so.1: sqlplus: fatal: /s01/orabase/product/10.2.0/dbhome_1/lib32/libclntsh.so.10.1 : wrong ELF class:  ELFCLASS32

这里可以看到引起wrong ELF class的库文件(libclntsh.so.10.1)位于lib32目录下,说明该库文件是32位的。

一般来说只有安装了64位oracle软件时会同时出现lib和lib32 这2个存放库文件的目录, 当安装了32位oracle软件时则只会显示lib一个目录。 这也是判断所安装的Oracle数据库软件是64 bit 还是 32 bit的一种方法。

以上问题一般是由于设置了不正确的LD_LIBRARY_PATH 环境变量 , 或者 lib 目录、libclntsh.so.10.1权限不正确引起的。

建议通过以下步骤排查问题:


1. 检查 sqlplus 命令相关的so共享库文件

[oracle@vrh1 ~]$ ldd `which sqlplus` 
        linux-vdso.so.1 =>  (0x00007fff0bbfd000)
        libsqlplus.so => /s01/orabase/product/10.2.0/dbhome_1/lib/libsqlplus.so (0x00002b450f6b4000)
        libclntsh.so.10.1 => /s01/orabase/product/10.2.0/dbhome_1/lib/libclntsh.so.10.1 (0x00002b450f89b000)
        libnnz10.so => /s01/orabase/product/10.2.0/dbhome_1/lib/libnnz10.so (0x00002b4510ec6000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003635c00000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003635800000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003636000000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003639800000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003635400000)
        libaio.so.1 => /usr/lib64/libaio.so.1 (0x00002b45122ab000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003635000000)

2. 找出以上输出中与所报错误中文件名相符的记录,如错误中所报的so文件的路径名为

/s01/orabase/product/10.2.0/dbhome_1/lib32/libclntsh.so.10.1

而 64位 sqlplus 所需要的64位 so文件 的路径为

/s01/orabase/product/10.2.0/dbhome_1/lib/libclntsh.so.10.1

3. 以上说明可能是LD_LIBRARY_PATH 变量存在问题 , 检查该变量
 
echo $LD_LIBRARY_PATH 

/s01/orabase/product/10.2.0/dbhome_1/lib32:/s01/orabase/product/10.2.0/dbhome_1/lib

一般来说在64位的情况下 需要将 lib 目录 放置在 该LD_LIBRARY_PATH 变量的前面,如

export LD_LIBRARY_PATH= $ORACLE_HOME/lib:$ORACLE_HOME/lib32


4. 若检查发现LD_LIBRARY_PATH 变量没有问题, 那么可以进一步检查 lib 和lib32 这2个目录的权限 ,以及相关so 文件是否对 other组有必要的r-x权限。

也可以通过9.2.0.8 和 10g中自带的 changePerm.sh脚本来修复问题,该脚本一般位于$ORACLE_HOME/install目录下

su  - oracle

$ cd $ORACLE_HOME/install
$ ./changePerm.sh


Where is the script changePerm.sh?

Applies to:
Oracle Server - Enterprise Edition - Version: 9.2.0.8 to 10.2.0.5.0 - Release: 9.2 to 10.2
Information in this document applies to any platform.
Goal
Where is the script changePerm.sh?
Solution


During patch set installation, all new files and directories are created with restricted access, 
by default. Users or third party applications with a different group identifier from that of the database, 
which try to access client-side utilities or libraries in the database home, 
will see permission errors when trying to access these files or directories.

changePerm.sh is a script that allows users that do not belong to the database group to 
access and execute files in the ORACLE_HOME directory. Only run this script when absolutely 
required as it will reduce security. The script (borne shell) loops through a hard-coded set of 
files and directories, extracts the "group" permissions, and set the "other" permissions the 
same as the group's permissions. By doing so, "other" users are able to execute 
these files and change to these directories

The script is located in the ORACLE_HOME/install directory on Unix and Linux systems 
(there is no equivalent for Windows). 
This script ships with Oracle Database versions 9.2.0.8 and Oracle 10g releases. 

The changePerm.sh file is not available nor necessary for Oracle Database Server 11.1 
and above because in 11g, 
permissions under the Oracle Home (including "others") are set correctly/relaxed.

Output when the changePerm.sh script is executed:

$ cd $ORACLE_HOME/install
$ ./changePerm.sh
-------------------------------------------------------------------------------
Disclaimer: The purpose of this script is to relax permissions on some of the
files in the database Oracle Home so that all clients can access them.
Please note that Oracle Corporation recommends using the most restrictive file
permissions as possible for your given implementation. Running this script
should be done only after considering all security ramifications.
-------------------------------------------------------------------------------

Do you wish to continue (y/n) : y
Finished running the script successfully

Please see /tmp/changePerm_err.log for errors and /tmp/changePerm.log for the log of events

This script should be run by Oracle Software owner to relax the permission 
and can be run while database processes are active.

Note :
1. If you are patching Oracle RAC home, then you will need to run this script on all the nodes
2. Oracle recommends using the most restrictive file permissions 
possible for your given implementation. Run this script only after considering 
all security ramifications and only if you need to share this installation



Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *