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
It might be the exact same privs that are in CONNECT and RESOURCE. I
would have to make that decision when the time came. But I wouldn't
do it with the default role names that the entire world knows.
So I would create my own roles and then substitute those names for
CONNECT and RESOURCE.
--
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)
Received on Tue Dec 07 2004 - 10:51:28 CST
