Re: Looking for opinions...

If you're concerned about the group possibly shooting themselves in the foot by dropping or altering the tables, you could use system triggers (create trigger restrict_drop before drop on schema ...). For the DML privileges, you could also trigger on those events and possibly check some of the connectivity and/or tool information. For example, if they logged in via SQL*Plus or some other direct tool (instead of the application), you could raise an error if they tried to delete or update data. While this isn't foolproof since wise users know about DBMS_APPLICATION_INFO, it is probably enough to keep things safe from non-technical business staff.

Obviously, there are some side effects of triggers that must be considered, but you're looking for suggestions...not necessarily good suggestions :).

May the force be with you.

Dan

• Original Message ---- From: "Sweetser, Joe" <JSweetser_at_icat.com> To: oracle-l_at_freelists.org Sent: Thursday, January 31, 2008 10:37:45 AM Subject: Looking for opinions...

Situation
is
a
"generic"
database
account
that
too
many
people
know
the
password
to.
But
they
need
to
know
the
password
for
valid
business
reasons.
Does
it
make
more
sense
to
limit
that
account's
access
to
its'
own
tables
or
create
a
new
account(s)
and
grant
those
the
specific
access
they
need?
I
like
the
second
option
for
various
reasons
(auditability
(is

that
a
word?)
and
accountability
to
name
two)
but
others
think
just
controlling
the
generic
account's
access
to
objects
is
fine.
To
be
a
little
more
clear
(and

one
reason
why
I
don't
like
the
first
option),
there
would
be
different
privs
on
different
tables
-
select
only
on
table
A;
select,
insert
on
table
B;
select,
update
on
Table
C;
etc).
Even
with
using
roles,
something
just
sort
of
bugs
me
about
an
owner/account
not
being
to
update
its'
own
data
(read-only

situation
exceptions,
of
course).

Opinions/comments/suggestions?
Feel
free
to
send
back-channel
and
I
will
summarize
since
I
don't
think
this
falls
under
a
technical
umbrella.
:-)

Thanks,
-joe

--
http://www.freelists.org/webpage/oracle-l