RE: Permission to see the procedures

  • From: "Kline.Michael" <Michael.Kline@xxxxxxxxxxxx>
  • To: "Thomas Biju" <BThomas@xxxxxxxxxx>, <spatenau@xxxxxxxxx>
  • Date: Fri, 11 Feb 2005 09:47:43 -0500

The select_catalog_role doesn't seem to work. That made sense. Maybe
that's why it didn't work.

The need to view the code is stated to be that the DEV database may have
"new changes" not on PRD. And they have 4 "dev" databases.

So, if he gets a call at 2AM, then he wants to be able to see production
code.

I'm also tinkering with the thought that I may kick off a flat text
report 1 to x times per day and put it in a "public" place where they
can look at that.

Or perhaps change their "procedures" like I had done at VDH where I make
them install changes with a script and that script can go into a "read
only" area. But with TOAD and other tools it's so easy to lose control.

The developer would like to go into TOAD with "schema browser" and
simply pull up the procedure to view.

Management has no problems with the viewing, but doesn't want him able
to change and recompile.

(It's sort of one of those "security" things. There are generic jobs
that can be run under Maestro, and if he has access to those, he could
run a list script, and then make changes and possibly run a compile
script. He wouldn't have the owner password, but the job would run as
the owner.

This is almost like our conversation over cron when we can also use
dba_jobs.)

Just need that magic grant that allows "select only" privs to a
package/procedure/body.

Michael Kline
Database Administration
Outside 804.261.9446
Cell 804.744.1545
3-9446
 
> -----Original Message-----
> From: Thomas Biju [mailto:BThomas@xxxxxxxxxx]
> Sent: Thursday, February 10, 2005 5:20 PM
> To: spatenau@xxxxxxxxx; Kline.Michael
> Cc: oracle-l@xxxxxxxxxxxxx
> Subject: RE: Permission to see the procedures
> 
> Try granting the SELECT_CATALOG_ROLE....
> 
> Thanks,
> Biju
> 
> 
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Steven Patenaude
> Sent: Thursday, February 10, 2005 2:35 PM
> To: Michael.Kline@xxxxxxxxxxxx
> Cc: oracle-l@xxxxxxxxxxxxx
> Subject: Re: Permission to see the procedures
> 
> 
> On Thu, 10 Feb 2005 15:21:29 -0500, Kline.Michael
> <Michael.Kline@xxxxxxxxxxxx> wrote:
> > The development folks would like to be able to view the procedures,
> > packages, etc., on a production reporting database, but we do *NOT*
want
> > them to be able change anything.
> >
> > This is sort of like a "read only" access to packages, procedures,
> > triggers, etc.
> >
> > I would think this would be like a "select any view" but I don't see
any
> > thing there.
> >
> > Can this be done by granting some sort of privs to a role and then
> > giving them the role?
> 
> There is the dba_source view.  I've created a procedure before that
> pretty prints the source and given the devs exec privs.  That keeps
> them out of the data dictionary, and the procedure allows you to have
> close control over who sees what, if that is your business need.
> 
> That was developed back in O7.  There might be a new feature since
> then that makes this easier.
> 
> Steven
> --
> //www.freelists.org/webpage/oracle-l
> 
> 
>
________________________________________________________________________
_____________________________
> ________
> 
> This electronic transmission and any attached files are intended
solely for the person or entity to
> which they are addressed and may contain information that is
privileged, confidential or otherwise
> protected from disclosure. Any review, retransmission, dissemination
or other use, including taking
> any action concerning this information by anyone other than the named
recipient, is strictly
> prohibited. If you are not the intended recipient or have received
this communication in error,
> please immediately notify the sender and destroy this communication. 
************************************************ 
The information transmitted is intended solely 
for the individual or entity to which it is  
addressed and may contain confidential and/or 
privileged material. Any review, retransmission, 
dissemination or other use of or taking action 
in reliance upon this information by persons or 
entities other than the intended recipient is 
prohibited. If you have received this email in 
error please contact the sender and delete the 
material from any computer. [ST:A234] 
************************************************ 
--
//www.freelists.org/webpage/oracle-l

Other related posts: