Sebastian Kirsch: Blog

Friday, 03 March 2006

Oracle auth mysteries

Filed under: — Sebastian Kirsch @ 14:15

Judging from my experience with Oracle databases, one of the most arcane mysteries is this: How does Oracle do authorization and authentication? Especially as processes at the “fringe” of normal operations are concerned – for example when connecting to an idle instance or when authenticating as a system user.

For those unfamiliar with Oracle, it ships with two system users: “sys” with a password of “change_on_install", and “system” with a password of “manager". These passwords can be changed after initializing a new Oracle instance, and will be stored in the database. They can also be stored in an external password file for remote logins.

But what if no Oracle instance exists? New Oracle instances are created by Oracle itself – it’s kinda like pulling yourself out of the swamp by your own bootstraps (or by your own hair, if you are Baron M√ľnchhausen.) To do this, you use sqlplus, the Oracle commandline tool, and connect to an idle instance. This instance is started by sqlplus upon logon, but does not contain a database. So where does the authorization info come from? How does Oracle determine that you are allowed to start up an idle instance?

To start an idle instance, you have to the “SYSDBA” privilege. When no database exists, this privilege is inferred from the group membership of the operating system user starting sqlplus. This group is called the “SYSDBA” group in the Oracle documentation, and it is usually set to “dba". So if you create a unix group “dba” and create a user which is member of this unix group, this user has the “SYSDBA” privilege as far as Oracle is concerned.

You can then (as the aforementioned user) set the environment variable ORACLE_SID to the SID of the new instance and execute “sqlplus sys as sysdba” or “sqlplus / as sysdba". sqlplus will start up an idle Oracle instance and connect to it. You can then use this instance to create a new database. (Do not set the environment variable TWO_TASK – this variable is only used for non-local connections. But you can only connect to an idle instance via local connections.)

Here is the rub: How does Oracle determine the name of the unix group which has the SYSDBA privilege?

This information is hidden in the file $ORACLE_HOME/rdbms/lib/config.s or $ORACLE_HOME/rdbms/lib/config.c, depending on the platform; one is an assembler file, the other is a C source file. On Solaris, it is an assembler file (presumably because Solaris does not ship with a C compiler out of the box), and there is a part in it that looks like this:

                        .L12:
/* 0x0008         15 */         .ascii  "dba\0"
/* 0x0014         20 */         .align  8

.L13: /* 0x0014 22 */ .ascii “dba\0″

So to change the unix group with the SYSDBA privilege, you have to change the string constants in this assembler file, assemble it (there’s a makefile in the directory that does this for you,) and then relink the oracle binary. How is that for a (seemingly simple) configuration change?

This information applies to Oracle 9 and Oracle 10; if you are still on Oracle 8, you have to use “sqlplus /nolog” and then say “connect internal” to connect to an idle instance. (As far as I remember; I do not have an Oracle 8 instance handy at the moment.) The privilege is called “CONNECT INTERNAL” instead of “SYSDBA". But changing the group name is done by the same means.

More info about this can be found in this AskTom article. If there is anything wrong with this article, please contact me; I am no Oracle DBA, I just spent many happy hours chasing after Oracle login problems.

Comments

No comments yet.

RSS feed for comments on this post.

Leave a comment

Sorry, the comment form is closed at this time.


Copyright © 1999--2004 Sebastian Marius Kirsch webmaster@sebastian-kirsch.org , all rights reserved.