Howard J. Rogers wrote:
> Anurag Varma wrote:
>
>> "DA Morgan" <damorgan_at_x.washington.edu> wrote in message
>> news:1102389346.899684_at_yasure...
>>
>>> Anurag Varma wrote:
>>>
>>>
>>>> "DA Morgan" <damorgan_at_x.washington.edu> wrote in message
>>>> news:1102349725.487447_at_yasure...
>>>>
>>>>
>>>>> Niall Litchfield wrote:
>>>>>
>>>>>
>>>>>
>>>>>>> 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. This is not
>>>>>> quite the
>>>>>> same thing.
>>>>>
>>>>>
>>>>> I agree. But I have read elsewhere specific advice to drop them as
>>>>> they
>>>>> are a security risk just by existing. Alternatively one can keep the
>>>>> roles but drop those privs from them that are inappropriate.
>>>>>
>>>>> I disagree that dropping CONNECT and RESOURCE will screw up any
>>>>> aspect of Oracle. But if you insist certainly one could edit those
>>>>> default roles to remove inappropriate privileges. What end-user,
>>>>> for example, needs the ability to create clusters and database links?
>>>>> And what DBA would want them to if they even knew what they were?
>>>>> --
>>>>> Daniel A. Morgan
>>>>> University of Washington
>>>>> damorgan_at_x.washington.edu
>>>>> (replace 'x' with 'u' to respond)
>>>>
>>>>
>>>>
>>>> connect, resource roles are used by oracle scripts themselves.
>>>> Dropping them will not be good. I'm not sure why
>>>> you are still sticking to your advice of dropping them:
>>>>
>>>> Try this in the rdbms/admin dir:
>>>>
>>>> egrep -i 'grant ' *.* | egrep -i ' (connect|resource)( |,)'
>>>> a0801070.sql: execute immediate 'GRANT DEBUG CONNECT SESSION TO
>>>> JAVADEBUGPRIV';
>>>> c0703040.sql: 'grant connect, resource, execute any
>>>> procedure to outln',
>>>> c0800050.sql: 'grant connect, resource, execute any
>>>> procedure to outln',
>>>> catqm.sql:grant resource to xdb;
>>>> catsnmp.sql:grant connect to OEM_MONITOR;
>>>> catsnmp.sql:grant resource to OEM_MONITOR;
>>>> catsnmp.sql:grant CONNECT, SELECT ANY DICTIONARY to DBSNMP;
>>>> catxdbr.sql:Rem nagarwal 11/05/01 - grant DML privileges to
>>>> resource view
>>>> csminst.sql:grant connect, resource, dba to csmig
>>>> dbmslsby.sql:Rem jnesheiw 07/23/02 - grant connect, resource
>>>> to logstdby_administrator
>>>> dbmslsby.sql:GRANT CONNECT, RESOURCE TO logstdby_administrator;
>>>> jvmsec5.sql:GRANT DEBUG CONNECT SESSION TO JAVADEBUGPRIV;
>>>> migrate.bsq:grant connect, resource, dba to migrate identified by
>>>> migrate;
>>>> owmctab.plb:grant connect, resource, create public synonym, drop
>>>> public synonym, create role to wmsys;
>>>> owmu901.plb:grant connect, resource, create public synonym, drop
>>>> public synonym to wmsys;
>>>> prvtbiau.plb:1 GRANT CONNECT THROUGH :
>>>> sql.bsq:grant connect to outln
>>>> sql.bsq:grant resource to outln
>>>> utlsampl.sql:GRANT CONNECT,RESOURCE,UNLIMITED TABLESPACE TO SCOTT
>>>> IDENTIFIED BY TIGER;
>>>>
>>>>
>>>> Anurag
>>>
>>>
>>> Because they are security holes. Perhaps it is just me but I read
>>> scripts before I run them and edit them where appropriate.
>>>
>>> I absolutely fail to see why anyone would grant CONNECT knowing it
>>> is giving each and every end user the ability to create a database
>>> link. It may not be a problem where many of you work ... but in a
>>> security conscious environment ... it just makes no sense: At least
>>> to me.
>>> --
>>> Daniel A. Morgan
>>> University of Washington
>>> damorgan_at_x.washington.edu
>>> (replace 'x' with 'u' to respond)
>>
>>
>>
>> Fine. Then tell me what privs you would really grant the outln, wmsys,
>> oem_monitor, logstdby_administrator and csmig users? .. if
>> you
>> plan on dropping connect, resource from your database
>> What would you edit the above lines to?
>> How would you figure out what privs to grant by looking at a wrapped
>> pl/sql code (see owmctab.plb above)?
>> mind reading I guess!
>>
>> Anurag
>
>
>
>
> And a related question. When you've deleted the roles, and invented your
> own substitutes, and stored outlines don't work or workspace management
> produces odd results... and Oracle Support turns round and washes their
> hands of you... what do you do then?
>
> Regards
> HJR
I am very well aware of several defense contractors and government
agencies that have dropped these roles and not one has been denied
support from Oracle. Thanks for the FUD.
--
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)
Received on Tue Dec 07 2004 - 10:55:46 CST
