Re: securing pg_proc

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, List pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: securing pg_proc
Date: 2005-03-17 21:30:12
Message-ID: 1111095012.11750.269.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2005-03-17 22:34:22 depended on table types
Previous Message Tom Lane 2005-03-17 21:20:33 Lockfile restart failure is still there :-(