"Howard J. Rogers" wrote:
> "Ryan Gaffuri" <rgaffuri_at_cox.net> wrote in message
> news:1efdad5b.0301140410.2144954f_at_posting.google.com...
> > "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message
> news:<HAKU9.23596$jM5.62538_at_newsfeeds.bigpond.com>...
> > > <tunity5_at_yahoo.com> wrote in message
> > > news:32bcd267.0301131002.713015ff_at_posting.google.com...
> [snip]
> > >
> > > Regards
> > > HJR
> >
> > couldnt you use the data dictionary to see who has DBA priviledges?
>
> First of all, there is no such thing as a DBA 'privilege'. There is a DBA
> *role*, and you could certainly see who has been granted that role by
> querying an appropriate DBA_ view in the data dictionary.
>
> But the owner of that role would not have the rights to shutdown, startup,
> backup or restore a database, nor create one in the first place. Only the
> holder of the SYSDBA privilege (or SYSOPER, with restrictions) can do that.
>
> The problem is that if you are using O/S authentication of privileged users,
> then you can't actually grant SYSDBA to anyone. You grant the 'privilege' by
> modifying group memberships at the O/S level. If you use passwordfile
> authentication, you also can't grant the SYSDBA privilege to anyone if the
> password file is a shared one: only SYS (and INTERNAL in earlier versions)
> could have an entry in such a file.
>
> If the password file is exclusive, then the V$ view I mentioned shows you
> which 'real' users have an entry in the password file, and thus to whom the
> SYSDBA privilege has been granted. Whilst the V$ views aren't technically
> part of the data dictionary, they are close enough to count, I think.
>
> Regards
> HJR
It is also important to note that the DBA role as supplied by Oracle with the
database is not necessarily, the hopefully isn't, the DBA role in any
production Oracle database. So just finding a ROLE named DBA says nothing about
the privileges it may contain.
Daniel Morgan
Received on Tue Jan 14 2003 - 15:28:37 CST
