Re: Switch off Fine Grained Access Control within database packaged procedures

Neil wrote:
>
> <snip>
>
> > Exactly what problem are you facing?
> >
> > HTH -- Mark D Powell --
>
> A simplified example (i hope!)
>
> I have a parts catalogue with a policy that restricts part/serial numbers by
> supplier
> A time based life information table for each part/serial number has a
> similar policy.
>
> I have a form that shows me time based information for my part/serial.
>
> eg
> Date : dd-MON-yyyy
>
> Part Number Serial Number
> Life Info
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 99999999
> 99999999 99999999
>
> I use a procedure to get this time based information.
>
> When i execute a query on the parts catalogue, a predicate gets built and i
> see only my part/serial numbers. This is fine.
> A Post Query has a call to the procedure to retrieve the life usage
> information relevant to the date entered
> I dont want the procedure to use FGAC, since i already know i can see the
> part/serial number as it's already been applied to the base table and i am
> passing the part/serial into the procedure.
>
> Clear as mud?
>
> Neil

So you have a table which has FGAC to define which data you can and can't see. And you want to be able to see data that you are not currently allowed to see. Is that correct?

IMO, your security model needs to accurately reflect the requirements of your job. If you are supposed to be able to see this data, then the FGAC policy should be adjusted accordingly. If you are not supposed to see this data, then the FGAC policy is doing what it should. In either case, it is probably not the procedure you are using that needs to be fixed.

Cheers,
Brian

-- 
===================================================================

Brian Peasland
dba_at_remove_spam.peasland.com

Remove the "remove_spam." from the email address to email me.


"I can give it to you cheap, quick, and good. Now pick two out of
 the three"