I am curious if you have resolved this issue. I wonder if this is at
all related to the Fine Grained Security. In general, when you grant
"select" privilege to a user, you also gives him the right to lock the
rows in the table. So the grantee can issue "select ... for update.."
on the table. This SQL just identifies the rows that are needed and
locks them so nobody else can modify them. However, if the grantee
subsequently try to actually "update" the rows, errors will be raised,
as the grantee does not have "update" privilege. So, the point is, you
can issue a "select .. for update" without actually carrying out the
"update".
"Ronnie Yours" <ronnie_yours_at_yahoo.com> wrote in message news:<am7fka$47k$1_at_nntp-m01.news.aol.com>...
> Hi,
>
> I am in the process of implementing fine grain security on our databases and
> it works great except for the fact that when it comes to Lobs it doesnt seem
> to work, especially in case of updates.
>
> Is it a known issue or am I doing something wrong.
>
> In my database certain users can see a record but cannot update it.
>
> The problem is when trying to update a clob field I need to do a select
> for... update and this selects the row for update irrespective of the
> security on it. This is because the user has select rights on the row . But
> the user should not be able to issue a select ... for update because he/she
> does not have update rights on the row.
>
> Now using dbms_lobs.write the user can write into a lob field even if he
> does not have priveleges to do it.
> Please suggest.
>
> Thanks
> Ronnie
Received on Fri Sep 20 2002 - 15:42:55 CDT
