Re: securing pg_proc - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: securing pg_proc
Date
Msg-id 1111095012.11750.269.camel@localhost.localdomain
Whole thread Raw
In response to Re: securing pg_proc  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
List pgsql-hackers
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.

...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?

That would open up the market for pay-for add-ons to PostgreSQL. It
would also encourage packaged app vendors to port their code to
PostgreSQL, in the knowledge that their source code would be secure.
[Dont jump on my case... not everybody thinks open source is cool enough
to actually do it themselves... and I accept their position]

Best Regards, Simon Riggs



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Lockfile restart failure is still there :-(
Next
From: Andrew Dunstan
Date:
Subject: depended on table types