Re: viewing source code

On Dec 20, 2007 11:30 AM, Roberts, Jon <Jon(dot)Roberts(at)asurion(dot)com> wrote:
> > -----Original Message-----
> > From: Merlin Moncure [mailto:mmoncure(at)gmail(dot)com]
> > Sent: Thursday, December 20, 2007 8:30 AM
> > To: Roberts, Jon
> > Cc: Alvaro Herrera; Trevor Talbot; Joshua D. Drake; Kris Jurka; Jonah H.
> > Harris; Bill Moran; pgsql-performance(at)postgresql(dot)org
> > Subject: Re: [PERFORM] viewing source code
> >
>
> > On Dec 20, 2007 9:07 AM, Roberts, Jon <Jon(dot)Roberts(at)asurion(dot)com> wrote:
> > > So your suggestion is first to come up with a query that dynamically
> > checks
> > > permissions and create a view for it. Secondly, change pgAdmin to
> > reference
> > > this view in place of pg_proc. Actually, it should be extended to all
> >
> > This solution will not work. It requires cooperation from pgAdmin
> > which is not going to happen and does nothing about psql or direct
> > queries from within pgadmin. Considered from a security/obfuscation
> > perspective, its completely ineffective. As I've said many times,
> > there are only two solutions to this problem:
> >
> > 1. disable permissions to pg_proc and deal with the side effects
> > (mainly, pgadmin being broken).
> >
> > 2. wrap procedure languages in encrypted handler (pl/pgsql_s) so that
> > the procedure code is encrypted in pg_proc. this is an ideal
> > solution, but the most work.
> >
>
> I think there is an option 3. Enhance the db to have this feature built in
> which is more inline with commercial databases. This feature would drive
> adoption of PostgreSQL. It isn't feasible in most companies to allow
> everyone with access to the database to view all code written by anyone and
> everyone.

option 3 is really option 2. having this option is all the flexibility
you need. i understand in certain cases you want to prevent code from
being available to see from certain users, but i don't buy the
adoption argument...most people dont actually become aware of
implications of pg_proc until after development has started. simply
having a choice, either directly community supported or maintained
outside in pgfoundry should be enough. in the majority of cases, who
can see the code doesn't matter.

i do however strongly disagree that hiding the code is bad in
principle... i was in the past in this exact situation for business
reasons out of my control (this is why I know the pgadmin route wont
work, i've chased down that angle already), so i'm highly sympathetic
to people who need to do this. i opted for revoke from pg_proc route,
which, while crude was highly effective.

merlin