Command srvctl without SUDO – CRS-0254: authorization failure

Siguiendo desde un poco con el tema de seguridad a nivel usuarios de OS, por politica tambien puede ocurrir que no podamos hacer sudo a comandos de administración impersonandonos en el usuario oracle.

Cuando trabajamos en RAC la cosa se pone un poco mas dificil, ya que debemos utilizar comandos de cluster que suben y bajan instancias , entre otras tareas.

Vamos a trabajar en nuestro ejemplo con el comando srvctl que es el más familiar, por lo que venimos posteando y por que es el mismo concepto para el resto de los comandos que precisamos.

Si quisieramos ejecutar comandos de oracle con nuestro usuario ( en este ejemplo useros ) deberiamos:

• Verificar que estemos en el grupo oinstall para ejecucion de algunos comandos que no impliquen logueranos a la base.
• Verificar que estemos en el grupo dba en el caso que nuestro usuario se pueda loguear a la base con privilegios dba.
• Verificar que tengamos algun script que exporte las variables de entorno , para poder ejecutar estos comandos.

Ahora que verificamos estos pasos, estamos en condiciones de hacer :

sqlplus /
lsnrctl
dgmgrl
dbca
netca
emca
emctl
rman /
srvctl

Y todos los comandos que se encuentran en el $ORACLE_HOME/bin

Ahora bien, como dijimos antes algunas cosas se ponen dificiles por que cuando voy a ejecutar el comando srvctl sufro el error:

 CRS-0254:  authorization failure.

Como ? no habiamos chequeado los permisos y grupos ?

Si lo hicimos, pero al trabajar en cluster los comandos que controlan las instancias, servicios , asm , etc no funcionan !!

1) Exportamos las variables.

[useros@tstdat01lx ~]$ export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_test
[useros@tstdat01lx ~]$ export ORACLE_SID=TESTDAT1
[useros@tstdat01lx ~]$ export PATH=$PATH:$ORACLE_HOME/bin:./
[useros@tstdat01lx ~]$ export EDITOR=vi

2) Ejecutamos el comando y nos arroja error.

[useros@tstdat01lx bin]$ srvctl start instance -d TESTDAT -i TESTDAT1 -o open
PRKP-1001 : Error starting instance TESTDAT1 on node tstdat01lx
CRS-0254:  authorization failure

Vamos a analizarlo .

Las instancias y servicios pueden ser manejadoss por comandos que se ejecutan en cluster.

Con el usuario oracle los ejecuto y no tengo ningun problema (El problema es que ya nos los puedo utilizar !!)

Reviso los permisos del comando srvctl y estan correctos:

[useros@sdat3106lx bin]$ ls -ltrh srvctl
-rwxr-xr-x  1 oracle oinstall 6.2K Mar 30  2009 srvctl

El usuario useros pertence al grupo oinstall, por lo tanto podria ejecutarlo.

El problema radica en que los permisos de los comandos de cluster son asignados por comandos que se encuentran en el home del CRS.

Por ejemplo el comando crs_getperm .

Ahora vamos a dar un ejemplo del poder de los mismos.

Esta tarea yo la ejecute desde el primer nodo , pero podria ser desde cualquiera (Lo probe y funciono OK.)

Vamos a la configuración y asignación de permisos entonces.

Recordemos pedir el uso de oracle, y trabajemos en los permisos mientras dure.

Debemos mirar que privilegios tenemos sobre las instancias a administrar. Por ejemplo : Base TESTDAT – instancia TESTDAT1

• Nos paramos en los binarios del home del crs.

[useros@tstdat01lx bin]$ cd /u01/app/oracle/product/10.2.0/crs_pre/bin

• Ahora Consultamos los permisos.

[useros@tstdat01lx bin]$ crs_getperm ora.TESTDAT.TESTDAT1.inst
Name: ora.TESTDAT.TESTDAT1.inst
owner:oracle:rwx,pgrp:oinstall:rwx,other::r--,

Como podemos observar, los permisos son para :

oracle: all
oinstall:all
Other:read

Ahi esta nuestro problema. Por que estos comandos solo permiten al usuario oracle o grupo oinstall. (oinstall solamente si es ese nuestro grupo primario.)

Hay dos caminos.

Setear oinstall como nuestro grupo default primario con lo que ello involucra si particicipamos en varios grupos.

O configurar los permisos.

Yo elegi este último por razones obvias.

a) Agregamos los nuevos permisos. CON EL USUARIO ORACLE

• Para la instancia TESTDAT1

[oracle@tstdat01lx bin]$ crs_setperm ora.TESTDAT.TESTDAT1.inst -u user:useros:rwx

• Para la instancia TESTDAT2

[oracle@tstdat01lx bin]$ crs_setperm ora.TESTDAT.TESTDAT2.inst -u user:useros:rwx

• Por herencia afecta al comando srvctl start database , stop database.

b) Verificamos que estos cambios hayan sido impactados.

• En la instancia 2.

[oracle@tstdat02lx bin]$ crs_getperm ora.TESTDAT.TESTDAT2.inst
Name: ora.TESTDAT.TESTDAT2.inst
owner:oracle:rwx,pgrp:oinstall:rwx,other::r--,user:useros:rwx,

• En la instancia 1.

[oracle@tstdat02lx bin]$ crs_getperm ora.TESTDAT.TESTDAT1.inst
Name: ora.TESTDAT.TESTDAT1.inst
owner:oracle:rwx,pgrp:oinstall:rwx,other::r--,user:useros:rwx,

• En la Base.

[oracle@tstdat02lx bin]$ crs_getperm ora.TESTDAT.db
Name: ora.TESTDAT.db
owner:oracle:rwx,pgrp:oinstall:rwx,other::r--,

c) Realizamos la prueba.

[useros@tstdat02lx ~]$ srvctl stop instance -d TESTDAT -i TESTDAT1
[useros@tstdat02lx ~]$ srvctl start instance -d TESTDAT -i TESTDAT1 -o mount

Espero esto le haya sido de mucha utilidad, recordemos que en el articulo previo hice pie en que debemos tener un conocimiento previo de usuarios de sistema, para poder comprender que es lo que estabamos haciendo.
Prometo agregar un articulo a nivel Sistema Operativo, en la seccion linux la semana que viene.

Saludos !