Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Deadly sins againts database performance/scalability

Re: Deadly sins againts database performance/scalability

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Sat, 06 Dec 2003 00:05:21 -0800
Message-ID: <1070697955.199170@yasure>


Comments in-line.

Paul Drake wrote:
>
> what privileges do you actually require?

Select on v$ magic views required to see what is actually happening. One can start with v_$reserve_words and v_$open_cursor and if you have any imagination you can come up with dozens more.

>
> What if the DBA (person) removed all of the privileges from the DBA
> role except for create session, table, type, view, trigger, sequence,
> synonym and alter session?

If you read Oracle instructions, which apparently few do, no one should be granted the DBA role. The DBA role, like CONNECT and RESOURCE are intended in the same manner as SCOTT/TIGER. They are supposed to be dropped following installation and new roles created appropriate to employee job requirements. The rule is give employees the privileges they need to do their job. No privilege they don't need any more than denying privileges they do need.

> the problem with granting an app_owner schema the role DBA is that

This is a red herring. The DBA role, as provided by Oracle is supposed to be dropped.

> The more you read about security, the more that you'll agree with this
> viewpoint (IMHO).

In development. Sorry I don't buy you argument. In test yes. In staging yes. In production absolutely. But if developers do stupid things in development their work fails in test. So what? And that is what code reviews are supposed to catch long before anything goes to test. What you appear to be doing is handcuffing everyone because someone might do something if you let them.

> This is a gross oversimplification, I'm sure that you can find
> exceptions, but I believe it to be generally true.

I agree that it is a gross oversimplification. But I do not agree that it is generally true. I think a more generally true statement would be that DBAs inhibit the ability of developers to do their job and claim it relates to security. Then whine about the poor quality of what developers develop when it finally gets to production.

> Give the developers enough privileges to create objects in the own
> schemas in dev to get their work done, but not enough sys_privs to
> alter the app_owner schema(s) themselves.
>
> Pd

Why? Tell me exactly what it is the competently hired, competently trained, and competently managed developers are going to do if they actually modify the app_owner schema in development?

The only come up with two possible answers. 1. Produce better applications
2. Not hate DBAs

Both sound like good outcomes to me.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)
Received on Sat Dec 06 2003 - 02:05:21 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US