RE: V$ access for production support
- From: caseydyke@xxxxxxxxxxxxxxx
- To: "'oracle-l'" <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 04 Sep 2006 13:46:36 +1000
We use a fairly boring - but effective - combination of app_supp and
dba_supp roles and user based profiles (that are likewise generic). The
profiles limit the standard things like idle time, lios, cpu usage and
what not. Took a wee bit of effort to get them right (the settings that
is) - but they do work. We've also provided the Ops dbas a simple API
to set tracing for a support session upon login (just sets a 10046 trace
to capture SQL). Nothing fancy, but helped in jumping a couple of
security hurdles.
HTH
>
>
> > Tanel Poder <tanel.poder.003@xxxxxxx> wrote:
> >
> > Well someone malicious could cause some library cache latch contention
>
> > by
> > running PL/SQL or nested loop joins against unindexed columns of V$SQL
>
> > or
> > V$SQL_SHARED_MEMORY.
> >
> > So you'd need to:
> >
> > 1) work out which views would actually be needed for production
> support
> > 2) distinguish which views are dangerous and which are not and create
> > the
> > roles based on that
> > 3) give respective roles to the users based on how much you trust them
>
> > ;)
> >
> > Tanel.
> >
--
//www.freelists.org/webpage/oracle-l
Other related posts:
