From: A.M. <agentm@themactionfaction.com>
To: pgsql-performance@postgresql.org
Subject: Re: viewing source code
Date: Thu, 20 Dec 2007 12:39:55 -0500
Message-ID: <5ACACAC2-7171-411A-9DE0-F53FCE98EDBA@themactionfaction.com> (raw)
In-Reply-To: <1A6E6D554222284AB25ABE3229A92762112A49@nrtexcus702.int.asurion.com>
References: <1A6E6D554222284AB25ABE3229A92762112A49@nrtexcus702.int.asurion.com>
On Dec 20, 2007, at 11:30 AM, Roberts, Jon wrote:
>
>
>> -----Original Message-----
>> From: Merlin Moncure [mailto:mmoncure@gmail.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@postgresql.org
>> Subject: Re: [PERFORM] viewing source code
>>
>> On Dec 20, 2007 9:07 AM, Roberts, Jon <Jon.Roberts@asurion.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.
>
> For instance, you could have a Finance group writing functions to
> calculate
> your financial earnings. These calculations could be changing
> frequently
> and should only be visible to a small group of people. If the
> calculations
> were visible by anyone with database access, they could figure out
> earnings
> prior to the release and thus have inside information on the stock.
Does everyone in your organization have login access to your
database? That seems like the main issue. Perhaps you should stick an
application server in between. The application server could also
upload functions from the "Finance group" and ensure that no one can
see stored procedures.
Cheers,
M
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: agentm@themactionfaction.com
Subject: Re: viewing source code
In-Reply-To: <5ACACAC2-7171-411A-9DE0-F53FCE98EDBA@themactionfaction.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox