Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: OK to revoke privileges from SYS or DBA?

Re: OK to revoke privileges from SYS or DBA?

From: DA Morgan <damorgan_at_x.washington.edu>
Date: Mon, 06 Dec 2004 19:17:30 -0800
Message-ID: <1102389346.899684@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)
Received on Mon Dec 06 2004 - 21:17:30 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US