JL Computer Consultancy

OSOPER - Does anyone use this Unix role ?

August 1999


One of the early steps of installing Oracle for Unix is a prompt for 'the group having the dba privilege - default dba' and the very next is for 'the group having the oper privilege - default dba'. In this context, the group refers to the Unix groups as defined in the file /etc/group, and these screens allow you to associate Unix groups with a pair of Oracle roles - the OSOPER role and the OSDBA role.

These two roles are not visible in the normal dba_roles view, and their privileges cannot be changed (though it might be interesting to see what happens when you try to create a role called OSOPER or OSDBA). The roles exist to allow the database to be started and stopped by two different classes (groups) of users.

The OSDBA role allows an extreme level of control over databases - anyone connecting with this role effectively connects as the user SYS with the right to create or destroy great swathes of data at a whim. On the other hand, a user connected with the OSOPER role effectively connects as the 'user' PUBLIC and just enough privileges to start, stop, backup and recover the database.

Traditionally, it seems, the Oracle account is left as the only Unix account in the dba group, and the oper group is never used. Virtually every site I have visited seems to allow the overnight operators to log in (perhaps in some cunningly obscure fashion) as oracle to backup the database, a mechanism that leaves me feeling rather uncomfortable given the excessive power that this account owns.

There is one peculiar and tedious little problem with using the oper account, however, if you want to use it you need to relink the oracle executable - as noted above, the default group for the OSOPER privilege is the dba group, and if you change it the installation invokes a relink.

Checking the existence of the OSOPER role:

If you look in $ORACLE_HOME/rdbms/lib, you wil find a file called config.c which looks something like this:

        /*  SS_DBA_GRP defines the UNIX group ID for sqldba adminstrative access.  */
        /*  Refer to the Installation and User's Guide for further information.  */
        #define SS_DBA_GRP "dba"
        #define SS_OPER_GRP "oper"
        char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP};

If your definition of SS_OPER_GRP is "dba" then you have a standard install, and will not be able to use the OSOPER privilege. If the SS_OPER_GRP is defined to be anything other than dba then it is highly likely that you have a system with a usable OSOPER privilege. If you take any Unix account out of the dba group and put it into this "oper" group then that user will be able to start and stop the database without also having the right to smash it to bits.

If you have go the default install, then you can change it by editing the config.c file, and rebuilding the oracle executable using the supplied 'make' file, for example running the command:

        make -f ins_rdbms.mk oracle

will create an oracle executable in the local directory. You might want to check that this is the same size as the current executable (in case that has been patched and generated from somewhere else). If you are very confident that it is safe you could then run:

        make -f ins_rdbms.mk ioracle

which will regenerate the executable, move the old one to $ORACLE_HOME/bin/oracleO, and move the new one to the right place with the right permissions (so long as no processes are currently running the existing executable).

As a quick check - you can then log in to svrmgr from an 'oper' account and check your Oracle id:

        svrmgrl
        connect internal
        select user from dual;
should yield the result of PUBLIC

Back to Main Index of Topics