Yes. This is pretty bad. A simple SQL trace indeed confirms that row
level security policy is not checked when DBMS_LOB, unlike the regular
update, is used to modify the lob data. One more reason to be wary of
lob. First it was the materialized view fast refresh problem, and now
this. What to do with lob? Cann't live with it, cann't live without
it.
"Vladimir M. Zakharychev" <bob_at_dpsp-yes.com> wrote in message news:<amndf7$985$1_at_babylon.agtel.net>...
> Well, for me this is issue with FGAC where LOB update through DBMS_LOB
> bypasses FGAC update policy. For example, if you are attempting to modify
> a LOB via DBMS_LOB in a table for which you don't have UPDATE privilege,
> ORA-1031 will be raised, and this is expected (though one can SELECT FOR
> UPDATE from such table, as you noted). But if you do the same on a table
> where FGAC controls access, update policy is simply not enforced, that is
> DBMS_LOB does not verify if LOB write is in violation of the policy. This is
> not good, to say the least, as this allows for covert alteration of data in a
> policy-protected table and essentially defeats the purpose of FGAC, at least
> for LOBs... I verified that this issue exists on 8.1.7.4 and 9.2.0.1 - positive
> on both:
>
Received on Wed Sep 25 2002 - 02:14:33 CDT
