> "Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> > However, I'm a little unclear about where you stand on the relative
> > merit (whatever the implementation) of hiding at the very least
prosrc
> > from non-priv users.
>
> OK, in words of one syllable: I'm agin it.
> I think your proposal is a hack that solves one aspect of the general
> schema-info-protection problem, for just one category of requirements,
> and it does so in an intrusive and expensive fashion that will be a
> permanent backwards-compatibility problem whenever someone comes up
> with a more general solution. (Sooner or later, someone probably
> will, because we hear requests for this kind of thing often enough.)
> Also, it imposes the policy, the runtime cost to enforce the policy,
> and the compatibility issues on everyone whether they want that policy
> or not.
I don't buy the runtime cost issue at all. Internally the server does
not access pg_proc via sql so any overhead of a view is totally cut out
of the equation. But the other points are, I suppose, fairly
compelling.
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.
> There are other ways to solve it that have fewer side-effects. For
> instance you could imagine inventing a new PL "plprotected" in which
> the prosrc entry is a reference to some row in another table. The PL
> just fetches the function body from that table and passes it off to
the
> "real" PL. (A possible variant: the function body stays in prosrc,
but
> is encrypted.) This approach makes the feature optional and imposes
its
> costs only on those who want to pay them.
You've lost me here. What does securing the PL storage from low-priv
users have anything to with which PL I'm using? This is squarely a
database administration concern. If my requirement is to secure the
code on the server, then it should be irrespective of the PL language
choice.
Merlin
