Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: DBA user in Oracle conflicts during migration

Re: DBA user in Oracle conflicts during migration

From: <>
Date: 20 Feb 2005 14:16:55 -0800
Message-ID: <>

If you read exactly whay I wrote above, it was to process the data in a more or less unsupported database config (ala _allow_reset_logs_corruption) with the role 'dba' missing, exporting and importing it into a db with the role 'dba' intact.

Have you never had to pry open a corrupt database, only to export its contents and import it into a healthy db? Lucky you if you have not.

Again, the OP just wanted to get his data from Sybase into Oracle.
>Is there any workaround to have my user of 'dba' created ?

The above setup does qualify as a workaround to the problem. Does he want to do this in a production database? Probably not.

The remaining banter in this post does not really matter. If I felt like it, I would consider creating a database with a modified sql.bsq that lacks a role 'dba' but has a role 'notthedba' that has the exact same sys_privs and tab_privs granted to it, granted to the same user accounts.
Its approaching march madness here, and there are basketball games to watch, besides moving, etc. I'll leave it as an exercise for something with more interest, or as a possible SANS paper at a later time ;)

Others here have advocated removal of roles such as connect and resource entirely, I'm not standing alone on that one. Certainly oracle must support removing granted privileges from such roles in an attempt toward security by obscurity.

Typically, grants to such roles in the provided scripts are in cleartext, not wrapped (such as in the sql.bsq (worth a read - its in $ORACLE_HOME/rdbms/admin).

Roles are not what counts, its the system privileges (sys_privs) and object privileges (tab_privs) granted to the roles, granted to the user accounts that matter.
The oracle-provided schemas that have the dba granted by default do have the role 'dba' set as a default role, its not a role that is set during runtime (although it wouldn't hurt to audit for such use, to be thorough).
Provided that a similar role was constructed, and and additional sys_privs, tab_privs granted to such roles during patchset application and upgrades, I don't see how operation would be affected. It would be additional work, and a possible source of problems, so I would doubt that anyone would bother, outside of a very secure setting.

-bdbafh Received on Sun Feb 20 2005 - 16:16:55 CST

Original text of this message