Re: Sql Developer

You are absolutely right about philosophy and design, where I am coming from
the appropriate level of privileges is an application design decision.
Production DBA staff should *not* be defining application security levels,
though they might audit them, any more than they should define what
objects or relationships are implemented. *Developers* should be doing
that (so that when they say user HR wants alter session or drop any outline
as in the output below) they should be doing so deliberately.

eg


 1* select privilege from dba_sys_privs where grantee='HR'
USER @ clone >/

PRIVILEGE
----------------------------------------
ANALYZE ANY
CREATE TYPE
CREATE TABLE
ALTER SESSION
QUERY REWRITE
CREATE CLUSTER
CREATE SESSION
CREATE TRIGGER
CREATE SEQUENCE
DROP ANY OUTLINE
ALTER ANY OUTLINE
CREATE ANY OUTLINE
CREATE DATABASE LINK
CREATE MATERIALIZED VIEW

14 rows selected.



On 6/12/07, Kerber, Andrew W. <Andrew.Kerber@xxxxxxx> wrote:

 To a certain extent I disagree with Niall.  His issue with extra
privileges in development is the reason you need at least a 3 tier
environment,  In development, the developer should have any privileges that
are helpful for him to get his job done.  In the prod-cert environment, or
qa environment, or whatever you want to call it is where you make sure it
runs in the reduced set of privileges that the application is allowed in
production.  Its more a matter of design and development philosophy than
anything else.



-----Original Message-----
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Niall Litchfield
*Sent:* Tuesday, June 12, 2007 1:15 PM
*To:* rgravens@xxxxxxxxx
*Cc:* DennisCutshall@xxxxxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
*Subject:* Re: Sql Developer



On 6/12/07, *Rumpi Gravenstein* <rgravens@xxxxxxxxx> wrote:

What a user can browse is more a reflection on the privileges you've given
the user than insight into a tool's capabilities.  In the case you've
described, any user that can logon as Scott will be able to browse the same
objects.  What the tool is doing for you is shining some light on the
privileges the Scott account has been granted.  I would think that in a
development setting this would be a good thing as many of the system objects
should be helpful in the building of your applications.  In production the
privileges should be limited to what is needed.



An old curmudgeon disagrees. My take is that in development privileges
granted to the development schemas should only be what is needed as well,
and moreover that those privileges should be explicitly granted to the
development schema either directly or through a role as appropriate (how I
wish PL/SQL understood roles!). If you don't do this the following will
happen and be resolved in one of two ways.



The production schema will not be granted sufficient rights.



1. It will be resolved by granting blanket rights (CONNECT, RESOURCE as
per a lot of Oracle Corp code). or

2. It will be resolved by the dba determining appropriate rights (possibly
iteratively) and granting them in production.



Put another way what I am saying is that if it isn't done right in dev
then it will either not be done right in production or a different version
of the app will be being run in production.



Meanwhile someone originally asked about sqldeveloper! I think it's a
great tool but one that badly suffers from being an online development
environment and not a file based environment (that is the paradigm is that
you edit objects, don't create scripts), I don't mind an online environment
so long as it generates a repeatable, bulletproof build process.
sqldeveloper doesn't do that yet. (at least not straightforwardly). It is
however my third favourite IDE which isn't bad considering how long the
others have existed.

--
Niall Litchfield
Oracle DBA
http://www.orawin.info


------------------------------------------------------------------------------
NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the individual
or entity intended as the recipient. If you are not the intended recipient,
any use, copying, printing, reviewing, retention, disclosure, distribution
or forwarding of the message or any attached file is not authorized and is
strictly prohibited. If you have received this electronic mail message in
error, please advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments and any copies
of this message from your computer system. Thank you.


==============================================================================




--
Niall Litchfield
Oracle DBA
http://www.orawin.info

Other related posts: