RE: OEM permissions

[Norris, Gregory T [ITS]]

There's no reason I can see that he couldn't create the dblink first, and then reset 
the password using the encrypted value.  Alternately, the dblink could be created 
using the DBMS_SYS_SQL package... no knowledge of the current password required.

create database link foo
   connect to current_user
   using 'bar';

-Original Message-
Yong Huang
Sent: Saturday, December 20, 2003 2:29 PM
To: Multiple recipients of list ORACLE-L


Hi,

I think you're describing a real security hole. But I'm not sure how it's
exploited exactly. Let's say John Doe sets up his database on his desktop,
which is part of the production database network. He sees the hash value of
SYSTEM's password on production and sets the hash value for his own SYSTEM user
to be the same. Since now he doesn't know the clear text password for SYSTEM
(Pete Finnigan may know how to find it, though), he can't easily create a
private database link owned by SYSTEM. He can still create a public link, or a
private link owned by somebody else, his SYS user e.g. Then what?

(He can still create a link owned by SYSTEM from another account such as SYS
using a little bit hacking. But he won't know SYSTEM's password. I don't know
how security of the production database is compromised in any way)

Yong Huang

you wrote:

Maybe I'm a being a bit touchy here; but it seems that my comments about
having access to dba_users went completely unnoticed.  Let's put it this
way: There is NO WAY you can prevent somebody from setting up their own
private oracle instance.  It they have access to dba_users in your database,
they can create the SAME users with the SAME passwords in their private
database.  And they can create database links in their private database.

Now, is this a problem?

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Yong Huang
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Norris, Gregory T [ITS]
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

RE: OEM permissions

[Thomas A. La Porte]

I believe the point is not that you can create links to SYS or 
SYSTEM accounts, but instead to application accounts, e.g. if I 
created a link from my private database to the company's HR 
database using a duplicated HR_MANAGER schema, I may be able to 
access data that I otherwise should not have.

 -- Tom

Thomas A. La Porte, DreamWorks SKG
  

On Sat, 20 Dec 2003, Yong Huang wrote:

>Hi,
>
>I think you're describing a real security hole. But I'm not sure how it's
>exploited exactly. Let's say John Doe sets up his database on his desktop,
>which is part of the production database network. He sees the hash value of
>SYSTEM's password on production and sets the hash value for his own SYSTEM user
>to be the same. Since now he doesn't know the clear text password for SYSTEM
>(Pete Finnigan may know how to find it, though), he can't easily create a
>private database link owned by SYSTEM. He can still create a public link, or a
>private link owned by somebody else, his SYS user e.g. Then what?
>
>(He can still create a link owned by SYSTEM from another account such as SYS
>using a little bit hacking. But he won't know SYSTEM's password. I don't know
>how security of the production database is compromised in any way)
>
>Yong Huang
>
>you wrote:
>
>Maybe I'm a being a bit touchy here; but it seems that my comments about
>having access to dba_users went completely unnoticed.  Let's put it this
>way: There is NO WAY you can prevent somebody from setting up their own
>private oracle instance.  It they have access to dba_users in your database,
>they can create the SAME users with the SAME passwords in their private
>database.  And they can create database links in their private database.
>
>Now, is this a problem?
>
>__
>Do you Yahoo!?
>New Yahoo! Photos - easier uploading and sharing.
>http://photos.yahoo.com/
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Thomas A. La Porte
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

RE: OEM permissions

[Jared Still]

You could use protocol.ora to specify which machines are
allowed to make a connection to the database.

In some environments this would be fairly painless.

SAP for example.  The users do not connect to the database,
they connect to the app server.  The number of machines
that legitimately require a connection to the database
could be very limited.

This would reduce the possibility of someone sneaking in
through a database link.

Jared

On Sat, 2003-12-20 at 12:29, Yong Huang wrote:
> Hi,
> 
> I think you're describing a real security hole. But I'm not sure how it's
> exploited exactly. Let's say John Doe sets up his database on his desktop,
> which is part of the production database network. He sees the hash value of
> SYSTEM's password on production and sets the hash value for his own SYSTEM user
> to be the same. Since now he doesn't know the clear text password for SYSTEM
> (Pete Finnigan may know how to find it, though), he can't easily create a
> private database link owned by SYSTEM. He can still create a public link, or a
> private link owned by somebody else, his SYS user e.g. Then what?
> 
> (He can still create a link owned by SYSTEM from another account such as SYS
> using a little bit hacking. But he won't know SYSTEM's password. I don't know
> how security of the production database is compromised in any way)
> 
> Yong Huang
> 
> you wrote:
> 
> Maybe I'm a being a bit touchy here; but it seems that my comments about
> having access to dba_users went completely unnoticed.  Let's put it this
> way: There is NO WAY you can prevent somebody from setting up their own
> private oracle instance.  It they have access to dba_users in your database,
> they can create the SAME users with the SAME passwords in their private
> database.  And they can create database links in their private database.
> 
> Now, is this a problem?
> 
> __
> Do you Yahoo!?
> New Yahoo! Photos - easier uploading and sharing.
> http://photos.yahoo.com/
> -- 
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> -- 
> Author: Yong Huang
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051 http://www.fatcity.com
> San Diego, California-- Mailing list and web hosting services
> -
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jared Still
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

RE: OEM permissions

[Yong Huang]

Hi,

I think you're describing a real security hole. But I'm not sure how it's
exploited exactly. Let's say John Doe sets up his database on his desktop,
which is part of the production database network. He sees the hash value of
SYSTEM's password on production and sets the hash value for his own SYSTEM user
to be the same. Since now he doesn't know the clear text password for SYSTEM
(Pete Finnigan may know how to find it, though), he can't easily create a
private database link owned by SYSTEM. He can still create a public link, or a
private link owned by somebody else, his SYS user e.g. Then what?

(He can still create a link owned by SYSTEM from another account such as SYS
using a little bit hacking. But he won't know SYSTEM's password. I don't know
how security of the production database is compromised in any way)

Yong Huang

you wrote:

Maybe I'm a being a bit touchy here; but it seems that my comments about
having access to dba_users went completely unnoticed.  Let's put it this
way: There is NO WAY you can prevent somebody from setting up their own
private oracle instance.  It they have access to dba_users in your database,
they can create the SAME users with the SAME passwords in their private
database.  And they can create database links in their private database.

Now, is this a problem?

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Yong Huang
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

RE: OEM permissions

[Jamadagni, Rajendra]

That's why we have scripts which give us a report every few days on users that have 
db_links, any of the *_ANY_* privs (like alter any table), dba privs etc, also a list 
of some sensitive schemas too.

Our application support needed to work with users to grant/revoke roles and private 
synonyms. So, I wrote a package owned by "system" and completely controlled. Every 
action gets logged, even errors do get logged. If it finds unusual input, it goes to 
trace file. We are happy, app support is happy. That's the way we like it.

Raj 

-Original Message-
Sent: Friday, December 19, 2003 1:49 PM
To: Multiple recipients of list ORACLE-L



Maybe I'm a being a bit touchy here; but it seems that my comments about
having access to dba_users went completely unnoticed.  Let's put it this
way: There is NO WAY you can prevent somebody from setting up their own
private oracle instance.  It they have access to dba_users in your database,
they can create the SAME users with the SAME passwords in their private
database.  And they can create database links in their private database.

Now, is this a problem?
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jamadagni, Rajendra
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

RE: OEM permissions

[Jesse, Rich]

Sure it does, just not by default.  Check out the
07_DICTIONARY_ACCESSIBILITY parameter.

Enjoy!
Rich

Rich Jesse   System/Database Administrator
[EMAIL PROTECTED]  Quad/Tech Inc, Sussex, WI USA


-Original Message-
Sent: Friday, December 19, 2003 11:49 AM
To: Multiple recipients of list ORACLE-L


Hi, Raj,

9i doesn't allow a user with select any table privilege to view any object
owned by SYS. So the sys.link$ risk is gone. But select any dictionary, a
new
privilege in 9i, allows that. In practice, I always grant
select_catalog_role
to any developer, but refrain from granting select any dictionary or select
any
table. As DBAs, we should encourage developers to make full use of data
dictionary views and open the database to them as much as they can study it.
I
would help the consultant in your case instead of just throw back a "NO" to
him.

Yong Huang
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jesse, Rich
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

RE: OEM permissions

[Stephen.Lee]

Maybe I'm a being a bit touchy here; but it seems that my comments about
having access to dba_users went completely unnoticed.  Let's put it this
way: There is NO WAY you can prevent somebody from setting up their own
private oracle instance.  It they have access to dba_users in your database,
they can create the SAME users with the SAME passwords in their private
database.  And they can create database links in their private database.

Now, is this a problem?

> -Original Message-
> From: Michael Thomas [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 19, 2003 12:34 PM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: OEM permissions
> 
> 
> A possibly related question:
> I'm curious if everyone allows your developers to see
> V$SQL... views?  If not, then ... whatever ... no
> comment.
> 
> I'm disappointed with some perspectives in these
> threads regarding developers. Rather than close doors,
> why not use 'development' instances, and role based
> privs on the 'production' instance and grant the
> access required to the developers. E.g. Help them
> determine which Data Dictionary tables support their
> development?
> 
> Good luck.
> 
> --- Yong Huang <[EMAIL PROTECTED]> wrote:
> > Hi, Raj,
> > 
> > 9i doesn't allow a user with select any table
> > privilege to view any object
> > owned by SYS. So the sys.link$ risk is gone. But
> > select any dictionary, a new
> > privilege in 9i, allows that. In practice, I always
> > grant select_catalog_role
> > to any developer, but refrain from granting select
> > any dictionary or select any
> > table. As DBAs, we should encourage developers to
> > make full use of data
> > dictionary views and open the database to them as
> > much as they can study it. I
> > would help the consultant in your case instead of
> > just throw back a "NO" to
> > him.
> > 
> > Yong Huang
> > 
> > Jamadagni, Rajendra wrote:
> > 
> > Dennis,
> > 
> > "select any table" has to be a big no no ... anyone
> > can select from sys.link$.
> > But I am still trying how OEM can be used for
> > _development_?? what am I
> > missing? As for ...
> > One of our groups hired a new consultant and he
> > (claimed to have DBA
> > background) immediately shot off an email saying he
> > needed "select any table"
> > and "select catalog role" to do his work. We shot
> > off reply "Thanks for your
> > email, while we appreciate your requirements for
> > development, the privileges
> > you are requesting are a tad different than we grant
> > other developers. However
> > we request that you submit a justification for these
> > privileges and tell us how
> > your development would be affected without these and
> > we will accommodate your
> > request". This was 3 months ago and we _still_
> > haven't heard back.
> > 
> > __
> > Do you Yahoo!?
> > New Yahoo! Photos - easier uploading and sharing.
> > http://photos.yahoo.com/
> > -- 
> > Please see the official ORACLE-L FAQ:
> > http://www.orafaq.net
> > -- 
> > Author: Yong Huang
> >   INET: [EMAIL PROTECTED]
> > 
> > Fat City Network Services-- 858-538-5051
> > http://www.fatcity.com
> > San Diego, California-- Mailing list and web
> > hosting services
> >
> -
> > To REMOVE yourself from this mailing list, send an
> > E-Mail message
> > to: [EMAIL PROTECTED] (note EXACT spelling of
> > 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB
> > ORACLE-L
> > (or the name of mailing list you want to be removed
> > from).  You may
> > also send the HELP command for other information
> > (like subscribing).
> 
> 
> __
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> -- 
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> -- 
> Author: Michael Thomas
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051 http://www.fatcity.com
> San Diego, California-- Mailing list and web hosting services
> -
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message B

RE: OEM permissions

[Michael Thomas]

A possibly related question:
I'm curious if everyone allows your developers to see
V$SQL... views?  If not, then ... whatever ... no
comment.

I'm disappointed with some perspectives in these
threads regarding developers. Rather than close doors,
why not use 'development' instances, and role based
privs on the 'production' instance and grant the
access required to the developers. E.g. Help them
determine which Data Dictionary tables support their
development?

Good luck.

--- Yong Huang <[EMAIL PROTECTED]> wrote:
> Hi, Raj,
> 
> 9i doesn't allow a user with select any table
> privilege to view any object
> owned by SYS. So the sys.link$ risk is gone. But
> select any dictionary, a new
> privilege in 9i, allows that. In practice, I always
> grant select_catalog_role
> to any developer, but refrain from granting select
> any dictionary or select any
> table. As DBAs, we should encourage developers to
> make full use of data
> dictionary views and open the database to them as
> much as they can study it. I
> would help the consultant in your case instead of
> just throw back a "NO" to
> him.
> 
> Yong Huang
> 
> Jamadagni, Rajendra wrote:
> 
> Dennis,
> 
> "select any table" has to be a big no no ... anyone
> can select from sys.link$.
> But I am still trying how OEM can be used for
> _development_?? what am I
> missing? As for ...
> One of our groups hired a new consultant and he
> (claimed to have DBA
> background) immediately shot off an email saying he
> needed "select any table"
> and "select catalog role" to do his work. We shot
> off reply "Thanks for your
> email, while we appreciate your requirements for
> development, the privileges
> you are requesting are a tad different than we grant
> other developers. However
> we request that you submit a justification for these
> privileges and tell us how
> your development would be affected without these and
> we will accommodate your
> request". This was 3 months ago and we _still_
> haven't heard back.
> 
> __
> Do you Yahoo!?
> New Yahoo! Photos - easier uploading and sharing.
> http://photos.yahoo.com/
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> -- 
> Author: Yong Huang
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing).


__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Michael Thomas
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

RE: OEM permissions

[Yong Huang]

Hi, Raj,

9i doesn't allow a user with select any table privilege to view any object
owned by SYS. So the sys.link$ risk is gone. But select any dictionary, a new
privilege in 9i, allows that. In practice, I always grant select_catalog_role
to any developer, but refrain from granting select any dictionary or select any
table. As DBAs, we should encourage developers to make full use of data
dictionary views and open the database to them as much as they can study it. I
would help the consultant in your case instead of just throw back a "NO" to
him.

Yong Huang

Jamadagni, Rajendra wrote:

Dennis,

"select any table" has to be a big no no ... anyone can select from sys.link$.
But I am still trying how OEM can be used for _development_?? what am I
missing? As for ...
One of our groups hired a new consultant and he (claimed to have DBA
background) immediately shot off an email saying he needed "select any table"
and "select catalog role" to do his work. We shot off reply "Thanks for your
email, while we appreciate your requirements for development, the privileges
you are requesting are a tad different than we grant other developers. However
we request that you submit a justification for these privileges and tell us how
your development would be affected without these and we will accommodate your
request". This was 3 months ago and we _still_ haven't heard back.

__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Yong Huang
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

RE: OEM permissions

[jo_holvoet]

I believe a role 'OEM_MONITOR' is created in 9i when you create a DB; 
pre-9i you can create it yourself (via catsnmp.sql or something like that) 
and you can use that instead of granting specific other privileges. Oracle 
claims that it contains a minimum set of privileges for OEM use, but maybe 
you can trim it down further for your specific needs.
There are several notes on MetaLink about this; e.g. 216731.1.

mvg/regards

Jo






DENNIS WILLIAMS <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
12/18/2003 16:34
Please respond to ORACLE-L

 
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc: 
        Subject:    RE: OEM permissions


Raj - Thanks for your reply. Were this a consultant, my reply would mirror
yours, and maybe not so diplomatically. 
   But basically I manage these databases on behalf of this manager, so 
when
he asks for "read-only" access, I can't really refuse. And I think he is
pretty competent as a DBA. He says that he prefers to use OEM instead of
Toad.
   What I'm really asking is what could these grants be used for besides
just reading data? If there are other actions that could be done, I could 
at
least ask him not to perform those actions, so if something bad happens I
have provided an alert ahead of time.
   For those who use OEM in your environment, does the SELECT_CATALOG_ROLE
and SELECT ANY DICTIONARY privileges sound pretty usual for OEM to be able
to scout out the info it needs to paint the pretty displays?
   Yes, I am checking out how this exposes links and what is available on
the other systems the links point to. I have also asked his group not to
create any database links. Fortunately we have relatively few links.
   Again, thanks for your advice.

Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED] 

-Original Message-
Sent: Thursday, December 18, 2003 7:54 AM
To: Multiple recipients of list ORACLE-L


Dennis,

"select any table" has to be a big no no ... anyone can select from
sys.link$. But I am still trying how OEM can be used for _development_??
what am I missing? As for 

One of our groups hired a new consultant and he (claimed to have DBA
background) immediately shot off an email saying he needed "select any
table" and "select catalog role" to do his work. We shot off reply "Thanks
for your email, while we appreciate your requirements for development, the
privileges you are requesting are a tad different than we grant other
developers. However we request that you submit a justification for these
privileges and tell us how your development would be affected without 
these
and we will accommodate your request". This was 3 months ago and we 
_still_
haven't heard back.

Raj


Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !


-Original Message-
Sent: Thursday, December 18, 2003 8:24 AM
To: Multiple recipients of list ORACLE-L


We have a new manager that wants his group to use OEM for development
access, as an alternative to Toad. He has requested a special Oracle 
userid
with the following grants:
 SELECT_CATALOG_ROLE
 SELECT ANY DICTIONARY
 SELECT ANY TABLE

Does this seem reasonable for OEM? The manager is responsible for the data
in the database, so I don't see a problem with him viewing the data. There
are few database links, and I'll be reviewing them. Any ideas on what
mischief could occur? Thanks.




**
This e-mail message is confidential, intended only for the named
recipient(s) above and may contain information that is privileged, 
attorney
work product or exempt from disclosure under applicable law. If you have
received this message in error, or are not the named recipient(s), please
immediately notify corporate MIS at (860) 766-2000 and delete this e-mail
message from your computer, Thank you.

**5
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jamadagni, Rajendra
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: DEN

RE: OEM permissions - thanks!

[DENNIS WILLIAMS]

Raj, Thomas, Brad, Bill, anyone I forgot - I feel better about the situation
now. Thanks for letting me run this issue past you.

Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED] 

-Original Message-
Sent: Thursday, December 18, 2003 9:35 AM
To: Multiple recipients of list ORACLE-L


Raj - Thanks for your reply. Were this a consultant, my reply would mirror
yours, and maybe not so diplomatically. 
   But basically I manage these databases on behalf of this manager, so when
he asks for "read-only" access, I can't really refuse. And I think he is
pretty competent as a DBA. He says that he prefers to use OEM instead of
Toad.
   What I'm really asking is what could these grants be used for besides
just reading data? If there are other actions that could be done, I could at
least ask him not to perform those actions, so if something bad happens I
have provided an alert ahead of time.
   For those who use OEM in your environment, does the SELECT_CATALOG_ROLE
and SELECT ANY DICTIONARY privileges sound pretty usual for OEM to be able
to scout out the info it needs to paint the pretty displays?
   Yes, I am checking out how this exposes links and what is available on
the other systems the links point to. I have also asked his group not to
create any database links. Fortunately we have relatively few links.
   Again, thanks for your advice.

Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED] 

-Original Message-
Sent: Thursday, December 18, 2003 7:54 AM
To: Multiple recipients of list ORACLE-L


Dennis,

"select any table" has to be a big no no ... anyone can select from
sys.link$. But I am still trying how OEM can be used for _development_??
what am I missing? As for 

One of our groups hired a new consultant and he (claimed to have DBA
background) immediately shot off an email saying he needed "select any
table" and "select catalog role" to do his work. We shot off reply "Thanks
for your email, while we appreciate your requirements for development, the
privileges you are requesting are a tad different than we grant other
developers. However we request that you submit a justification for these
privileges and tell us how your development would be affected without these
and we will accommodate your request". This was 3 months ago and we _still_
haven't heard back.

Raj


Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !


-Original Message-
Sent: Thursday, December 18, 2003 8:24 AM
To: Multiple recipients of list ORACLE-L


We have a new manager that wants his group to use OEM for development
access, as an alternative to Toad. He has requested a special Oracle userid
with the following grants:
 SELECT_CATALOG_ROLE
 SELECT ANY DICTIONARY
 SELECT ANY TABLE

Does this seem reasonable for OEM? The manager is responsible for the data
in the database, so I don't see a problem with him viewing the data. There
are few database links, and I'll be reviewing them. Any ideas on what
mischief could occur? Thanks.




**
This e-mail message is confidential, intended only for the named
recipient(s) above and may contain information that is privileged, attorney
work product or exempt from disclosure under applicable law. If you have
received this message in error, or are not the named recipient(s), please
immediately notify corporate MIS at (860) 766-2000 and delete this e-mail
message from your computer, Thank you.

**5
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jamadagni, Rajendra
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: DENNIS WILLIAMS
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  Y

RE: OEM permissions

[Odland, Brad]

I would say OEM for dbas only. To difficult to manage for developers.

Dangerous. Too much low level stuff for managers and developers to poke
around with.

OEM is not really a development tool. 

2 cents




-Original Message-
Sent: Thursday, December 18, 2003 8:24 AM
To: Multiple recipients of list ORACLE-L



Wouldn't this allow viewing DBA_USERS?
I haven't tried this myself, but it seems that I could set up another oracle
instance, create a user identified by values, then create database link.

> -Original Message-
> 
> We have a new manager that wants his group to use OEM for development
> access, as an alternative to Toad. He has requested a special 
> Oracle userid
> with the following grants:
>  SELECT_CATALOG_ROLE
>  SELECT ANY DICTIONARY
>  SELECT ANY TABLE
> 
> Does this seem reasonable for OEM? The manager is responsible 
> for the data
> in the database, so I don't see a problem with him viewing 
> the data. There
> are few database links, and I'll be reviewing them. Any ideas on what
> mischief could occur? Thanks.
> 
> Dennis Williams
> DBA
> Lifetouch, Inc.
> [EMAIL PROTECTED] 
> -- 
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> -- 
> Author: DENNIS WILLIAMS
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051 http://www.fatcity.com
> San Diego, California-- Mailing list and web hosting services
> -
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).
> 
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: <[EMAIL PROTECTED]
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Odland, Brad
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

RE: OEM permissions

[Mercadante, Thomas F]

Dennis,

I think you are probably ok with this.  But the best way to do this is to
create an Oracle account, grant what he asks, and start OEM using that
account.  Try and change things and see what happens.  Then you will know
for sure what the impact is.

Good Luck!

Tom Mercadante
Oracle Certified Professional


-Original Message-
Sent: Thursday, December 18, 2003 10:35 AM
To: Multiple recipients of list ORACLE-L


Raj - Thanks for your reply. Were this a consultant, my reply would mirror
yours, and maybe not so diplomatically. 
   But basically I manage these databases on behalf of this manager, so when
he asks for "read-only" access, I can't really refuse. And I think he is
pretty competent as a DBA. He says that he prefers to use OEM instead of
Toad.
   What I'm really asking is what could these grants be used for besides
just reading data? If there are other actions that could be done, I could at
least ask him not to perform those actions, so if something bad happens I
have provided an alert ahead of time.
   For those who use OEM in your environment, does the SELECT_CATALOG_ROLE
and SELECT ANY DICTIONARY privileges sound pretty usual for OEM to be able
to scout out the info it needs to paint the pretty displays?
   Yes, I am checking out how this exposes links and what is available on
the other systems the links point to. I have also asked his group not to
create any database links. Fortunately we have relatively few links.
   Again, thanks for your advice.

Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED] 

-Original Message-
Sent: Thursday, December 18, 2003 7:54 AM
To: Multiple recipients of list ORACLE-L


Dennis,

"select any table" has to be a big no no ... anyone can select from
sys.link$. But I am still trying how OEM can be used for _development_??
what am I missing? As for 

One of our groups hired a new consultant and he (claimed to have DBA
background) immediately shot off an email saying he needed "select any
table" and "select catalog role" to do his work. We shot off reply "Thanks
for your email, while we appreciate your requirements for development, the
privileges you are requesting are a tad different than we grant other
developers. However we request that you submit a justification for these
privileges and tell us how your development would be affected without these
and we will accommodate your request". This was 3 months ago and we _still_
haven't heard back.

Raj


Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !


-Original Message-
Sent: Thursday, December 18, 2003 8:24 AM
To: Multiple recipients of list ORACLE-L


We have a new manager that wants his group to use OEM for development
access, as an alternative to Toad. He has requested a special Oracle userid
with the following grants:
 SELECT_CATALOG_ROLE
 SELECT ANY DICTIONARY
 SELECT ANY TABLE

Does this seem reasonable for OEM? The manager is responsible for the data
in the database, so I don't see a problem with him viewing the data. There
are few database links, and I'll be reviewing them. Any ideas on what
mischief could occur? Thanks.




**
This e-mail message is confidential, intended only for the named
recipient(s) above and may contain information that is privileged, attorney
work product or exempt from disclosure under applicable law. If you have
received this message in error, or are not the named recipient(s), please
immediately notify corporate MIS at (860) 766-2000 and delete this e-mail
message from your computer, Thank you.

**5
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jamadagni, Rajendra
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: DENNIS WILLIAMS
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGur

RE: OEM permissions

[DENNIS WILLIAMS]

Raj - Thanks for your reply. Were this a consultant, my reply would mirror
yours, and maybe not so diplomatically. 
   But basically I manage these databases on behalf of this manager, so when
he asks for "read-only" access, I can't really refuse. And I think he is
pretty competent as a DBA. He says that he prefers to use OEM instead of
Toad.
   What I'm really asking is what could these grants be used for besides
just reading data? If there are other actions that could be done, I could at
least ask him not to perform those actions, so if something bad happens I
have provided an alert ahead of time.
   For those who use OEM in your environment, does the SELECT_CATALOG_ROLE
and SELECT ANY DICTIONARY privileges sound pretty usual for OEM to be able
to scout out the info it needs to paint the pretty displays?
   Yes, I am checking out how this exposes links and what is available on
the other systems the links point to. I have also asked his group not to
create any database links. Fortunately we have relatively few links.
   Again, thanks for your advice.

Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED] 

-Original Message-
Sent: Thursday, December 18, 2003 7:54 AM
To: Multiple recipients of list ORACLE-L


Dennis,

"select any table" has to be a big no no ... anyone can select from
sys.link$. But I am still trying how OEM can be used for _development_??
what am I missing? As for 

One of our groups hired a new consultant and he (claimed to have DBA
background) immediately shot off an email saying he needed "select any
table" and "select catalog role" to do his work. We shot off reply "Thanks
for your email, while we appreciate your requirements for development, the
privileges you are requesting are a tad different than we grant other
developers. However we request that you submit a justification for these
privileges and tell us how your development would be affected without these
and we will accommodate your request". This was 3 months ago and we _still_
haven't heard back.

Raj


Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !


-Original Message-
Sent: Thursday, December 18, 2003 8:24 AM
To: Multiple recipients of list ORACLE-L


We have a new manager that wants his group to use OEM for development
access, as an alternative to Toad. He has requested a special Oracle userid
with the following grants:
 SELECT_CATALOG_ROLE
 SELECT ANY DICTIONARY
 SELECT ANY TABLE

Does this seem reasonable for OEM? The manager is responsible for the data
in the database, so I don't see a problem with him viewing the data. There
are few database links, and I'll be reviewing them. Any ideas on what
mischief could occur? Thanks.




**
This e-mail message is confidential, intended only for the named
recipient(s) above and may contain information that is privileged, attorney
work product or exempt from disclosure under applicable law. If you have
received this message in error, or are not the named recipient(s), please
immediately notify corporate MIS at (860) 766-2000 and delete this e-mail
message from your computer, Thank you.

**5
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jamadagni, Rajendra
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: DENNIS WILLIAMS
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

RE: OEM permissions

[Stephen.Lee]

Wouldn't this allow viewing DBA_USERS?
I haven't tried this myself, but it seems that I could set up another oracle
instance, create a user identified by values, then create database link.

> -Original Message-
> 
> We have a new manager that wants his group to use OEM for development
> access, as an alternative to Toad. He has requested a special 
> Oracle userid
> with the following grants:
>  SELECT_CATALOG_ROLE
>  SELECT ANY DICTIONARY
>  SELECT ANY TABLE
> 
> Does this seem reasonable for OEM? The manager is responsible 
> for the data
> in the database, so I don't see a problem with him viewing 
> the data. There
> are few database links, and I'll be reviewing them. Any ideas on what
> mischief could occur? Thanks.
> 
> Dennis Williams
> DBA
> Lifetouch, Inc.
> [EMAIL PROTECTED] 
> -- 
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> -- 
> Author: DENNIS WILLIAMS
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051 http://www.fatcity.com
> San Diego, California-- Mailing list and web hosting services
> -
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).
> 
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: <[EMAIL PROTECTED]
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

RE: OEM permissions

[Jamadagni, Rajendra]

Dennis,

"select any table" has to be a big no no ... anyone can select from sys.link$. But I 
am still trying how OEM can be used for _development_?? what am I missing? As for 

One of our groups hired a new consultant and he (claimed to have DBA background) 
immediately shot off an email saying he needed "select any table" and "select catalog 
role" to do his work. We shot off reply "Thanks for your email, while we appreciate 
your requirements for development, the privileges you are requesting are a tad 
different than we grant other developers. However we request that you submit a 
justification for these privileges and tell us how your development would be affected 
without these and we will accommodate your request". This was 3 months ago and we 
_still_ haven't heard back.

Raj

Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !


-Original Message-
Sent: Thursday, December 18, 2003 8:24 AM
To: Multiple recipients of list ORACLE-L


We have a new manager that wants his group to use OEM for development
access, as an alternative to Toad. He has requested a special Oracle userid
with the following grants:
 SELECT_CATALOG_ROLE
 SELECT ANY DICTIONARY
 SELECT ANY TABLE

Does this seem reasonable for OEM? The manager is responsible for the data
in the database, so I don't see a problem with him viewing the data. There
are few database links, and I'll be reviewing them. Any ideas on what
mischief could occur? Thanks.



**
This e-mail message is confidential, intended only for the named recipient(s) above 
and may contain information that is privileged, attorney work product or exempt from 
disclosure under applicable law. If you have received this message in error, or are 
not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 
and delete this e-mail message from your computer, Thank you.
**5
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jamadagni, Rajendra
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).