Skip site navigation (1) Skip section navigation (2)

Re: viewing source code

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Roberts, Jon" <Jon(dot)Roberts(at)asurion(dot)com>
Cc: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Trevor Talbot" <quension(at)gmail(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Kris Jurka" <books(at)ejurka(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, "Bill Moran" <wmoran(at)collaborativefusion(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: viewing source code
Date: 2007-12-20 17:43:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
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.


In response to

pgsql-performance by date

Next:From: Merlin MoncureDate: 2007-12-20 18:03:54
Subject: Re: viewing source code
Previous:From: A.M.Date: 2007-12-20 17:39:55
Subject: Re: viewing source code

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group