| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Permission to see the procedures
Michael,
It was suggested earlier this week or last to make a new version of Dba_Source in your production area. Then simply grant access to this view to the users.
Have you tried that?
Tom
-----Original Message-----
From: Kline.Michael [mailto:Michael.Kline_at_SunTrust.com]
Sent: Friday, February 11, 2005 9:48 AM
To: Thomas Biju; spatenau_at_gmail.com
Cc: oracle-l_at_freelists.org
Subject: RE: Permission to see the procedures
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_at_br-inc.com]
> Sent: Thursday, February 10, 2005 5:20 PM
> To: spatenau_at_gmail.com; Kline.Michael
> Cc: oracle-l_at_freelists.org
> Subject: RE: Permission to see the procedures
>
> Try granting the SELECT_CATALOG_ROLE....
>
> Thanks,
> Biju
>
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Steven Patenaude
> Sent: Thursday, February 10, 2005 2:35 PM
> To: Michael.Kline_at_suntrust.com
> Cc: oracle-l_at_freelists.org
> Subject: Re: Permission to see the procedures
>
>
> On Thu, 10 Feb 2005 15:21:29 -0500, Kline.Michael
> <Michael.Kline_at_suntrust.com> 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
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Fri Feb 11 2005 - 10:02:22 CST
 |
 |