> On Thu, 2005-03-17 at 13:36 -0500, Merlin Moncure wrote:
> > However, I still maintain that views are the perfect security
mechanism
> > for system catalogs. Imagine that all the system catalogs were all
> > views, and could be redefined or even dropped by the dba. They
would
> > present exactly the same stuff they do now, with rules presenting
them
> > just like the original table.
>
> > Now, for extreme situations like that government server that
requires
> > catalog security, the dba can redefine the various rules for the
catalog
> > views and lock various things down, using whatever methodology
he/she
> > sees fit. This would not affect the internal workings of the server
but
> > would affect the client tools, which is really what I'm after.
>
> Configurable security? Sounds great to me.
>
> This is exactly how Teradata implements this; they even present you
with
> a choice of views to load ontop of the catalog tables. Secure/Not. You
> choose.
That would be just great. Now why wouldn't this work?
> ...but in this case:
>
> > ( A possible variant: the function body stays in prosrc,
> > but
> > > is encrypted.)
>
> That sounds OK for this situation. Doesn't it Merlin?
Well, I think the idea has merit but there are complexities in the
implementation.
1. when is the encryption key first introduced (create function?) or is
it somehow supplied by the server?
2. is the encryption key stored? If so, where?
3. can the su decrypt functions without the key? (remembering he can
just attach a debugger and grab the source at some point)
4. can the decryption be integrated with the user security model, so
that decryption is tied to some other function?
In short, how could this be made to work? :-).
Merlin
