| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> 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
On 6/12/07, Kerber, Andrew W. <Andrew.Kerber_at_umb.com> 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_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Niall Litchfield
> *Sent:* Tuesday, June 12, 2007 1:15 PM
> *To:* rgravens_at_gmail.com
> *Cc:* DennisCutshall_at_mail.und.nodak.edu; oracle-l_at_freelists.org
> *Subject:* Re: Sql Developer
>
>
>
> On 6/12/07, *Rumpi Gravenstein* <rgravens_at_gmail.com> 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 -- http://www.freelists.org/webpage/oracle-lReceived on Tue Jun 12 2007 - 14:14:01 CDT
 |
 |