Re: V$ tables

My comments interspersed below.

Pete Finnigan wrote:

> <lots of snipping>

>
> Hi Daniel
>
> Good point about kill -9 and orakill, i will include those as the viable
> option to alter system kill. I mentioned the risk of alter system in the
> sans guide but didn't suggest an alternative, i will though.

Don't forget the simple matter of just writing a wrapper around ALTER SYSTEM to expose only a single functionality.

>
>
> ><RANT>
> >
> >But I would like any DBA out there that has ever had a bad experience with ALTER
> >SYSTEM, in a development enviornment, to step forward. I've yet to meet one. I
> >think this is paranoia with the same level of validity as many other Oracle myth
> >debunked here recently.
> >
>
> Its not paranoia, its common sense, give someone the keys to the door
> and someone at some point will try and turn that key. Also remember its
> not just the developer you have given it to that is the risk, if he has
> set his password weakly or his password is known, someone else can make
> use of his account. There are, as you know many other things that can be
> done with alter system, even a way to attempt to get passwords.

Two thoughts. First is that if someone does misuse it ... fire them. An employee that is given clear guidelines to follow and doesn't is worthless. Whether ALTER SYSTEM or stealing money from the cash drawer in my mind there is no difference. People are hired to do a job ... not play or steal.

With respect to passwords ... that is why Oracle made profiles and protocol.ora. There is nothing from stopping you from enforcing unique and complex passwords, from limiting logons, from limiting developers to specific IP addresses (like their own), etc. The tools are all there and can be easily put into place. Oncea gain in a matter of minutes.

>
>
> >And let me add that if the concern is that some developer will do something else
> >with ALTER SYSTEM other than kill their own sessions ... then perhaps that
> >developer should be escorted to the door and handed a letter of recommendation
> >to
> >present at the unemployment office. If developers are not free to utilize all of
> >the tools Oracle provides to do their job the end result will be exactly the
> >kind
> >of garbage I see in such abundance.
> >
> >I suggest a poll be conducted here of DBAs managing development databases.
> >Q1: Have you given access to DBMS_PROFILER to your developers?
>
> Never seen anyone use it except me, in fact i seem to remember reading
> somewhere (maybe Toms book) about using a home grown debug package with
> timestamps in it and a post processor to profile PL/SQL. I cannot
> remember the reason why this was better, if there was one.

Which was my point. It is the same thing as being scared about being attacked by a shark while swimming. Yeah it undoubtedly happens ... but so rarely it is not worth the worry. Just a simple warning, and enforcing it once, will keep any problem from ever happening again. One of the problems I see today is that management ... doesn't. It has become the pointy haired boss in the Dilbert cartoons a little more in many cases.

>
>
> >Q2: If not, why not?
>
> >Q3: If not how do you expect to receive decent code from developers?
>
> >Q4: If not, and without going to a book, or web site, and looking it up do you
> >know what DBMS_PROFILER is?
> >
> pl/sql profiler, I have only used it a couple of times.

I, developers I work with, and my students, use it regularly. I wouldn't even consider putting a procedure or package into production without it any more than I would write a select statement and not use EXPLAIN PLAN. Use of these tools should be encouraged by DBAs. Unless, of course, they prefer to just whine and complain about lousy development.

>
>
> cheers
>
> Pete
>
> >The prosecution rests.
> >
> ></RANT>
> >
> >Daniel Morgan
> >
>
> --
> pete_at_peterfinnigan.demon.co.uk
> pete_at_petefinnigan.com
>
> http://www.pentest-limited.com/oracle-security.htm - "Exploiting and
> protecting Oracle"
>
> http://online.securityfocus.com/infocus/1522 - "A simple Oracle Security
> Scanner"
>
> http://www.pentest-limited.com/default-user.htm - "Oracle Default User
> and Password List"
>
> http://www.pentest-limited.com/utl_file.htm - "Extracting Clear Text
> Passwords from the SGA"

Daniel Morgan Received on Fri Jul 12 2002 - 10:20:56 CDT