Re: OK to revoke privileges from SYS or DBA?

hpuxrac wrote:

> I cannot easily follow the thread here or understand exactly what Dan
> is advocating any longer.
>
> He seems to have acknowledged that recommending dropping the DBA role
> was a very bad piece of advice.
>
> Many people use these forums as sources of advice and wisdom.
>
> It is probably a good idea not to recommend something like this to
> others unless it is something that you have done in production and are
> willing to offer a detailed plan.
>
> Dan, have you dropped CONNECT and RESOURCE roles in production systems
> or is this something theoretical at this point?
>
> Academic discussions are all well and good but please make an effort to
> clearly define to an audience that often does not have the background
> that many of us do how much testing has gone into recommendations such
> as these.

Then let me clarify.

I routinely drop the CONNECT and RESOURCE roles when I install a database. I wrote that DBA should be dropped too and was quickly and decisively corrected by Tom Kyte and a correction that was well deserved because it is not something I actually do and my writing was, to put it mildly, sloppy. What I NEVER do is assign the role to anyone: ever! I build application related DBA roles specific to what the actual DBA is supposed to be doing and exclude any privs that are not required.

With respect to CONNECT and RESOURCE some have noted that these default roles are used by Oracle as part of the installation of some components. These are either components I don't use or I hand modify the scripts before they are run to point to other roles that I create.

But in the end, no matter what system privileges I use to build a production database I drop those privs after it is built that are not required for it to be utilized. Then when changes to the schema are required I put those specific privilege grants at the beginning of the change script and revoke them again when the modifications are completed. To have CREATE TABLE granted to a production schema where no one should be creating tables is, to me, a danger without value.

Yes my way of doing things requires a bit of extra work: No question about it. But then I often work in environments where security is more important than saving an hour or two a month.

HTH

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)