Re: implementing row level security

I had similar dilema, our model was quite complex (tree structure with some child tables) and we had to solve security on the node level. All the data were accessed through stored procedure (Insert, Update, Delete, Select). We started with Oracle RLS but after we decided to use our own solution
- one simple table with the node privileges and procedure for checking those rights.
We just put this checking procedure into our Insert/Update/Delete/Select procedures - that was the only way how to access the data. No grants on tables and schema locked.

jan

gnuoytr_at_rcn.com (robert) wrote in message news:<da3c2186.0404290715.3f1cf5c0_at_posting.google.com>...
> oracle 8.1.6/7
>
> i've read through the Finnigan, Kyte, OTN articles, and various threads
> on the ng. what i didn't find is a description (or assertion) that
> RLS is a simpler alternative to modifying an existing application
> code base for filtering table data.
>
> the case i have is like this:
>
> create table orders (order_num number, owner number, lots_data
> varchar2 (500) )
>
> create table personnel (user_id number, super_id number, more_data
> varchar2 (500) )
>
> a user should be able to see up the hierarchy, but only the individuals,
> not their orders (or any other related table data). down the
> hierarchy, individuals and their orders (and any other related table
> data). the issue is with filtering on the related tables; i think.
>
> there are about 6 to 10 related data tables. far as i can tell, just
> the one hierarchy table.
>
> the advantages to the RLS strategy: can be dropped in to any of our
> client installations; protects the data from out of application access.
> possible disadvantages: coding is actually more complicated than
> moding our application.
>
> i'm not looking for code (although i wouldn't say no), rather a "yes
> you can do this" using RLS and it is easy as pie (or pah as they say
> down south).
>
> thanks,
> robert
Received on Fri Apr 30 2004 - 11:43:26 CEST