thomas.kyte_at_oracle.com wrote:
> Niall Litchfield wrote:
>
>>DA Morgan wrote:
>>
>>>>can you provide a link as to where oracle advise dropping the dba
>>
>>role >
>>
>>>I've been asked this question before and tried to track down the
>>>reference unsuccessfully. This time, perhaps due to having some
>>>sleep over the weekend I was successful.
>>>
>>>
>>
> http://asktom.oracle.com/pls/ask/f?p=4950:8:9772908208972569857::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:7540675724395,
>
>>>And it is a very long URL so make sure it doesn't break up.
>>
>>www.tinyurl.com
>>
>>
>>>You will note the statement from the OP:
>>>I read your book and a article and read this quote where you have
>>
>>quoted
>>
>>>that "connect,resource and DBA should not be used in a system for
>>>security reasons".
>>>
>>>If it is good enough for Tom Kyte ... it is good enough for me to
>>>reference. ;-)
>>
>>Well possibly. Tom doesn't advocate *dropping* any of the roles - he
>>advocates not *using* them, on my reading anyway.
>
>
> Let me dis-ambiguate this totally
>
> a) DO NOT DROP DBA.
> b) don't use it if you don't have to.
>
> period. that is what the above links states. do not drop anything
> like that, that would be "a bad thing (tm)". there will be times when
> DBA is in fact needed (DBA is 'special', the very name is 'special' in
> the code)
>
> do not drop it
>
>
>
>>This is not quite the
>>same thing. In particular various bits and pieces that Oracle
>>themselves install create users using one or more of these roles
>
> (they
>
>>shouldn't but they do). Now if you are attempting to be secure you
>>wouldn't install bits and pieces of the supplied Oracle functionality
>>unless you were currently using them. So say, for example, that
>
> someone
>
>>comes along and decides that full text search would be a nice added
>>value feature for your database driven website. Fortunately Oracle
>>provides a rather nice set of functionality for this free of charge
>>with the database. Unfortunately dropping connect and resource will
>>rather screw up the installation of this functionality.
>>
>>I'd much rather REVOKE the privileges from users after the database
>>installation is complete.
>>
>>
>>>I am a firm believe in dropping all three roles and creating new
>>
>>roles,
>>
>>>perhaps with the same names though I prefer not, that meet
>>
>>specifically
>>
>>>defined and documented requirements for employee activities. If you
>>
>>can
>>
>>>not document a need for a privilege it should not be granted. It
>
> may
>
>>be
>>
>>>that no harm comes from it ... but no good can come of it either.
>
> So
>
>>>better to err on the side of security.
>
>
> do not drop connect, resource, dba - just DON'T USE THEM. As Niall
> said "big difference"
>
> do not drop them, it is the sure road to %@@!$
>
>
>>creating roles that have the same name as a well-known role but with
>
> a
>
>>different set of privileges is a sure-fire route to support hell.
>>
>>
>>
>>>And I'll go one step further while we are discussing security. Once
>
> a
>
>>>production schema is built ... the CREATE and ALTER privileges such
>>
>>as
>>
>>>CREATE PROCEDURE and ALTER TABLE should be dropped.
>>
>>I agree - of course this assumes that you have written apps that
>
> don't
>
>>need these privs in normal day to day operation :(.
>>Niall Litchfield
>>Oracle DBA
>>http://www.niall.litchfield.dial.pipex.com
Thanks for the clarification.
I'll change by advice to don't assign it to any user but rather
create your own internal role.
Thanks again.
--
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)
Received on Mon Dec 06 2004 - 10:19:08 CST
