I'm not saying it's not fixable. The
creation of dba level accounts such as dbsnmp and outln by Oracle is fixable as
well. But I'll wager there are folks out there who didn't know the
grants on the statspack tables were to public.
Of
course none of our developers or ad hoc query writers would ever write a
statement that doesn't use bind variables. I have it
on good authority that the same holds true for all Oracle sites
everywhere. :)
Ian
MacGregor
Stanford Linear Acclerator Center
-----Original Message-----Why not just backup the spctab.sql script and then in vi do a g:/PUBLIC/s//DBA or whatever
From: Rodd Holman [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 24, 2002 11:56 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Is Statspack a Security Problem?
role you choose to play with statspack before running. Although bind vars are still
appropriate too.
Rodd Holman
On Wed, 2002-07-24 at 12:23, kkennedy wrote:Sounds like yet another good reason for using bind variables 8-) Kevin Kennedy First Point Energy Corporation -----Original Message----- Sent: Wednesday, July 24, 2002 8:23 AM To: Multiple recipients of list ORACLE-L To wit: $grep -i grant spctab.sql <snip> grant select on STATS$SQLTEXT to PUBLIC; grant select on STATS$SQL_STATISTICS to PUBLIC; grant select on STATS$LEVEL_DESCRIPTION to PUBLIC; grant select on STATS$IDLE_EVENT to PUBLIC; grant select on STATS$PARAMETER to PUBLIC; grant select on STATS$STATSPACK_PARAMETER to PUBLIC; ----------------------------------------------------------------------------------------------- Notice the grants on stats$sqltext and stats$sql_summary. Should anyone who logs into the database be able to see nearly SQL run against it. Oracle appears to truncate alter user statements so that one cannot find 'alter user blatz identified by password;' but one may stumble on update sal_table set sal = 100 where empoyee_id = 5;' or something to that effect. Ian MacGregor Stanford Linear Accelerator Center [EMAIL PROTECTED]
