Re: Interesting Exploit in PL/SQL

ORA-20001 ? :) Assuming you've created a before noaudit trigger... Could be several reasons why someone has such a trigger. If the reason was a foolish developer playing around, then we lost with our approach, and an unwanted audit could stay in place. If it's legitimate, and the audit has to stay in place no matter what (which I suppose is the purpose of such a trigger) then no harm done either.

Aside from that, the "disable" procedure was sort of an emergency only thing. That would just turn off auditing wherever possible as quickly as possible, should problems - of performance or other nature - arise. And we really wouldn't want that to abort no matter what. And WHEN OTHERS THEN NULL; is just what we need.

Stefan

On 12/1/06, Niall Litchfield <niall.litchfield_at_gmail.com> wrote:
>
> On 12/1/06, Stefan Knecht <knecht.stefan_at_gmail.com> wrote:
> > Well yeah, for the 'enable' procedure we do. But when we try to disable
> it,
> > and Oracle doesn't like that, we just don't care - because if it can't
> be
> > disabled, it couldn't have been enabled in the first place :)
>
> Have a think about this then.
>
> SQL> CONN NIALL/JASPER_at_ASDB
> Connected.
> SQL> AUDIT INSERT ON T;
>
> Audit succeeded.
>
> SQL> ALTER TRIGGER AUDIT_TRIGGER ENABLE;
>
> Trigger altered.
>
> SQL> NOAUDIT INSERT ON T;
> NOAUDIT INSERT ON T
> *
> ERROR at line 1:
> ORA-00604: error occurred at recursive SQL level 1
> ORA-20001: AUDIT CHANGES NOT ALLOWED
> ORA-06512: at line 2
>
>
>
>
> --
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info
>

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