Re: implementing row level security

From: Tim Arnold <timkarnold_at_comcast.net>
Date: Thu, 29 Apr 2004 11:35:54 -0400
Message-ID: <GI-dnWmRItlBggzdRVn-hA_at_comcast.com>


"robert" <gnuoytr_at_rcn.com> 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

  I'm not quite sure what the question is, but whatever security you have in mind for the application can be yanked out and embedded in RLS. It may also be faster and eliminates an additional level of complexity in the application.
  If you are filtering for every 'select' in your app based on some user_group or whatever
- badda bing -gone. Received on Thu Apr 29 2004 - 17:35:54 CEST

Original text of this message