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: Dave <>
Date: Sun, 20 Feb 2005 23:14:41 GMT
Message-ID: <BR8Sd.19600$>

<> wrote in message
> 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

search for the thread, it is needed Received on Sun Feb 20 2005 - 17:14:41 CST

Original text of this message