Re: Jailing a schema from PUBLIC

Hey all,

Just wanted to let everyone know that I'm an idiot. I had never used simple single-table VIEWs to do DML before! <blush> When I have done DML through multi-table VIEWs, I used INSTEAD OF triggers, and I wasn't keen on creating 3000+ triggers for this project. And looking back, it makes sense because of the existence of the "WITH READ ONLY" clause in CREATE VIEW.

Thanks all for your help! The "jail" is working just fine.

Rich

> Rich. Rjamya
>
>>> wild idea,
>>>
>>> since public access is visible through ALL_* views, you can create local
>>> ALL_* views in schema B. These would be essentially same as regular views
>>> but you'd filter out owner A.
>
>
> The dictionary views are just that: views for your convenience. You can tell
> they aren't used by the SQL engine to do name and privilege resolution -
> just look at the recursive SQL in a trace file which always refers directly
> to the underlying dictionary tables (eg OBJ$, TAB$, SEG$, PRV$ etc etc).
> You can't spoof it into giving you more (or fewer) privileges. So if you've
> granted S/I/U/D to public on your first database, the only ways to close the
> door are
>

[snip]

--
http://www.freelists.org/webpage/oracle-l