developer privs in development (old thread inaccessible)

From: Paul Drake <drak0nian_at_yahoo.com>
Date: 6 Dec 2003 12:00:23 -0800
Message-ID: <1ac7c7b3.0312061200.7508f821@posting.google.com>

Hi Daniel.

I am unable to reply to the thread where your post was 85th. I'm including the

---

> On 5 Dec 2003, drak0nian_at_yahoo.com wrote:
>
>

>>the problem with granting an app_owner schema the role DBA is
>>that then the application is coded depending upon the DBA role
>>(and usually, all of the sys_privs that are in that role, that
>>the account invariably grants itself directly). it is such a
>>PITA to get changes made to remove queries that hit the dba_
>>views (such as dba_cons_columns for RI errors). If the
>>developers can't code against the dba_% views, but are limited
>>to the all_ views, you don't have as many issues when the code
>>runs on a qa db where the app owner account does not have the
>>DBA role granted to it.

>
>
> You are missing my point. I never want the user that the
> application will log in as to have anything but the priviledges
> that will be granted to it in public. What I want is a user that
> has dba priviledges (or a form thereof) that can be used by me
> and the development crew for the sole purpose of modifying the
> database for developing the app. I, most definitely, want to
> hamper the application schema exactly as I plan to in production.
>

What Paul Drake and so many others miss is that the security policy of a
company should be a written document. And the security rights and priviileges of an application should be part of a written specification.

If developers are required to create or modify applications based on those two documents then no application they create or modify can possibly violate the agreed security policies and specifications.

The only thing the developers could possibly do is make their jobs a bit
easier. Little things like looking up reserved words, checking to make sure that all of their dynamic SQL is using bind variables, looking at the numbers of hard and soft parses: In short all of the things Tom Kyte
does on his asktom website to demonstrate that things are working as they should.

The sad fact is, and since I don't know you Paul I'm not pointing at you
so don't take this personally, the DBAs that are most paranoid about giving developers privileges in development environments, are the DBAs that know the least about development: The ones that can't actually write and debug PL/SQL.

-- 
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)
======================================================================

Slashdot posted a topic similar, based upon the following article.

http://www.softwarereality.com/lifecycle/role_fragmentation.jsp

"Somehow over the past 10 years, a cancer has been growing inside
large organisations - called role fragmentation. As the roles have
fragmented, an entire non-industry has bloomed. Network
administration, database administration, security administration,
component administration, deployment administration, tool
administration. The list just goes on and on.

This fragmentation has had some seriously negative consequences for
the industry."

I don't pretend to know everything, I do hope that I know what works
best for my employer and our clients. I am certainly open to other
viewpoints that could make the developers more effective, while not
causing grief due to more rework due to a larger number of issues due
to permissions differing in dev and test environments.

I did not read that earlier thread from start to finish (85 posts?)
but will do so now, and would like to pick up that discussion here.
Again, I'm not able to post on that thread anymore, and saw little
choice but to start the thread anew.

thanks,

Paul

Received on Sat Dec 06 2003 - 14:00:23 CST