11.2 Job Seperation causes WARNINGS and ORA-15025 ORA-27041 With Certain Users (文档 ID 1317692.1)

11.2 Job Seperation causes WARNINGS and ORA-15025 ORA-27041 With Certain Users (文档 ID 1317692.1)

In this Document

APPLIES TO:

SYMPTOMS

You are seeing a flood of errors in the RDBMS alert log happens with certain users:

CAUSE

1. The problem is related to a user making a connection to try to execute a command to a datafile that they do not have the privilege to do so. When you connect to ASM, you are using a bequeath connection, therefore the instructions provided in the Note #391739.1 are close to this issue. However, the solution does not take into account Role Seperation:

a) Scenario : when the non oracle user tries to connect using sql*net i.e using listener
he is able to connect and access data.

The reason is typically that the Listener is started with the oracle user account, so the database server process (i.e. oracle) spawned by the Listener for a new connection is also running as oracle. The database server process for local connections, however, is spawned by the client process (e.g. SQL*Plus) and run as the operating system user that is running the client process.As the oracle user
belongs to disk group who has permissions to access there is no problem.

2)Scenario: when the non oracle user tries to connect using bequeath connection he is not able to access the data.

When connecting to the database with a BEQ (i.e. local) connection, the Oracle server process is spawned by the client program (e.g. SQL*Plus). If SQL*Plus is run as an operating system user other than oracle (i.e. the owner of the datafile system01.dbf), without the setuid bit set on oracle, the server process will run with the access rights of the user who started SQL*Plus, not of the oracle user.The non oracle user does not belong to group having the permissions..

SOLUTION

1) The oracle binary should have the setuidbit set

Setting the setuid bit on the oracle executable allows the oracle server process to run with the access rights of oracle even though it's being run by some other user. This gives read permissions on all oracle-owned datafiles and the shared memory segment(s) containing the SGA.

a.  The oracle executable should have the following permissions:

% ls -l $ORACLE_HOME/bin
-rwsr-s--x oracle dba 20917436 oracle

To change the oracle executable to match the above permissions, run the following command logged in as the oracle user:

% chmod 6751 $ORACLE_HOME/bin/oracle


b. Also, check the binary for the GRID user

-rwsr-s--x 1 oracle asmadmin 159110992 May 1 12:29 /opt/oracle/product/11.2.0/db/bin/grid


c.  In role separation the following group memberships should be established (or similiar)

grid: oinstall, asmadmin, asmdba, asmoper
oracle: oinstall, dba, oper, asmdba

Note: primary group is always oinstall, oracle needs to be member of asmdba

Group owner of the asm disks should be asmadmin

EXAMPLE
-------------

brw-rw---- 1 grid asmadmin 8, 1 Mar 29 11:09 ASMDATA01
brw-rw---- 1 grid asmadmin 8, 17 Jan 31 09:59 ASMDATA02
brw-rw---- 1 grid asmadmin 8, 33 Jan 31 09:59 ASMDATA03
brw-rw---- 1 grid asmadmin 8, 49 Jan 31 09:59 ASMDATA04

d.  Also, review the /etc/group allocation:

dba:x:232:oracle,grid
oinstall:x:506:
asmadmin:x:1000:grid
asmoper:x:1301:grid
asmdba:x:1300:oracle,grid

The user should belong to either the dba or the asmdba group, to be able to write to the ASM disks.

2)  In this case, the GRID guid was changed from asmdba to asmadmin and the errors have stopped.