Re: DBAs, roles and privs

Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1084761358.346651_at_yasure>...
> Marc Blum wrote:
>
> > On Sun, 16 May 2004 12:59:40 -0700, Daniel Morgan <damorgan_at_x.washington.edu>
> > wrote:
> >
> >
> >>Then, each and every week revoke the privileges you think most unlikely
> >>to be required and/or most dangerous. When someone complains about
> >>something you'll know the privilege was required and since you will know
> >>which one's you revoked you can provide a two-second fix. Eventually you
> >>will have a role that truly reflects the privs required.
> >>
> >>Other things I would do:
> >>1. Write a DDL trigger that makes it impossible to DROP, ALTER, or
> >>TRUNCATE any object. Code for this can be found at:
> >
> >
> > You're kiddin, aren't you?
> >
> > On a production system?
> >
> > Revoking some privilege and looking what happens? On a mission-critical system?
> >
> > I really don't give a damn if you're working for Boeing or Amazon, this advice
> > is not serious!
> >
> >
> > --
> > Marc Blum
> > mailto:blumNOSPAM_at_marcblum.de
> > http://www.marcblum.de
>
> Absolutely ... and always! And very serious.
>
> There is no excuse for DROP, ALTER, or TRUNCATE on a production system
> unless it is performed by the DBA.

ok. too bad that global temporary tables are not perfectly implemented.
yes, I know, the user should not have have the privs granted to them or a role directly, use package.proc for the table create/drop where GTTs are needed and grant exec on that.

yes, it would be best if such things ran in one statement, but that is not always possible. sometimes, permanent temporary tables need to be created, so that they can be analyzed, have indexes on them, etc.

There will be exceptions to such overly wide generalizations (thus rendering them invalid).

I think that we've had this discussion before.

Pd Received on Mon May 17 2004 - 13:28:59 CDT