Thread: Hide the code from users postgres

Hello

2010/6/24 akp geek <akpgeek@gmail.com>:
> Hi all -
>           Is there way in postgres to set the user privileges so that when
> they login , the user can not see functions and views?

you can't do it for user postgres.

Regards

Pavel Stehule

> Regards

On Thu, 2010-06-24 at 16:06 -0400, akp geek wrote:
> It's not for the user postgres.. If I have created a testuser, can I
> hide the code for that testuser?

No. Of course you have to wonder, "why" you would do that. It is the
data you are protecting, not the code to retrieve the data. Just make
sure they don't have access to the data.

Joshua D. Drake



--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering

On Thu, Jun 24, 2010 at 11:11 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> On Thu, 2010-06-24 at 16:06 -0400, akp geek wrote:
>> It's not for the user postgres.. If I have created a testuser, can I
>> hide the code for that testuser?
>
> No. Of course you have to wonder, "why" you would do that. It is the
> data you are protecting, not the code to retrieve the data. Just make
> sure they don't have access to the data.
>
> Joshua D. Drake
>
>
>
> --
> PostgreSQL.org Major Contributor
> Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
> Consulting, Training, Support, Custom Development, Engineering
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Seems akp would like to hide/protect (including his name) his hard
earned code/IP which may have consumed some man-hours, which to run,
requires well built and generously given PostgreSQL code which has
taken man-decades to develop.

Allan.

On Fri, 2010-06-25 at 00:00 +0300, Allan Kamau wrote:

>
> Seems akp would like to hide/protect (including his name) his hard
> earned code/IP which may have consumed some man-hours, which to run,
> requires well built and generously given PostgreSQL code which has
> taken man-decades to develop.
>

I have no problem with him trying to protect his hard earned work. I
just think he is trying to solve the wrong problem.

Joshua D. Drake

> Allan.
>

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering

On 24/06/2010 22:00, Allan Kamau wrote:
> Seems akp would like to hide/protect (including his name) his hard
> earned code/IP which may have consumed some man-hours, which to run,
> requires well built and generously given PostgreSQL code which has
> taken man-decades to develop.

There's been quite a bit of debate about this in the past, and as I
recall the short version is that it isn't practical or even particularly
desirable.... a trawl through the archives may be worthwhile.

This seems to be something of a FAQ, in fact.

Ray.


--
Raymond O'Donnell :: Galway :: Ireland
rod@iol.ie

On Thu, Jun 24, 2010 at 10:08 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> On Fri, 2010-06-25 at 00:00 +0300, Allan Kamau wrote:
>
>>
>> Seems akp would like to hide/protect (including his name) his hard
>> earned code/IP which may have consumed some man-hours, which to run,
>> requires well built and generously given PostgreSQL code which has
>> taken man-decades to develop.

And what is wrong with that? PostgreSQL has a licence that is intended
to work well with open and closed source works, and it is up to the
individual user to decide how they want to licence their apps built on
it.

> I have no problem with him trying to protect his hard earned work. I
> just think he is trying to solve the wrong problem.

It's a real problem faced by many businesses and solved by most
commercial DBMSs. Of course, it's basically impossible to solve in the
Open Source world, as there's nowhere to hide a key or obfuscation
algorithm. If akp geek is able to use EnterpriseDB builds of Postgres,
then he may want to look at PL/Secure, which will obfuscate his
pl/pgsql code:

http://www.enterprisedb.com/products/pl_secure_standard_server.do

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

On Thu, 2010-06-24 at 22:18 +0100, Dave Page wrote:

> > I have no problem with him trying to protect his hard earned work. I
> > just think he is trying to solve the wrong problem.
>
> It's a real problem faced by many businesses and solved by most
> commercial DBMSs. Of course, it's basically impossible to solve in the
> Open Source world, as there's nowhere to hide a key or obfuscation
> algorithm. If akp geek is able to use EnterpriseDB builds of Postgres,
> then he may want to look at PL/Secure, which will obfuscate his
> pl/pgsql code:
>
> http://www.enterprisedb.com/products/pl_secure_standard_server.do

That's interesting... does it just turn it into bytecode?

Joshua D. Drake

>

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering

2010/6/24 akp geek <akpgeek@gmail.com>:
> It's not for the user postgres.. If I have created a testuser, can I hide
> the code for that testuser?
> Regards
>

you can do it. But mostly of all instruments for postgres will not
work corectly - like pgAdmin and others. So this step is usually
unwanted.

try

REVOKE SELECT ON pg_proc FROM public;
REVOKE SELECT ON pg_view FROM public;





> On Thu, Jun 24, 2010 at 3:42 PM, Pavel Stehule <pavel.stehule@gmail.com>
> wrote:
>>
>> Hello
>>
>> 2010/6/24 akp geek <akpgeek@gmail.com>:
>> > Hi all -
>> >           Is there way in postgres to set the user privileges so that
>> > when
>> > they login , the user can not see functions and views?
>>
>> you can't do it for user postgres.
>>
>> Regards
>>
>> Pavel Stehule
>>
>> > Regards
>
>

2010/6/24 Joshua D. Drake <jd@commandprompt.com>:
> On Thu, 2010-06-24 at 22:18 +0100, Dave Page wrote:
>
>> > I have no problem with him trying to protect his hard earned work. I
>> > just think he is trying to solve the wrong problem.
>>
>> It's a real problem faced by many businesses and solved by most
>> commercial DBMSs. Of course, it's basically impossible to solve in the
>> Open Source world, as there's nowhere to hide a key or obfuscation
>> algorithm. If akp geek is able to use EnterpriseDB builds of Postgres,
>> then he may want to look at PL/Secure, which will obfuscate his
>> pl/pgsql code:
>>
>> http://www.enterprisedb.com/products/pl_secure_standard_server.do
>
> That's interesting... does it just turn it into bytecode?
>

probably it doesn't - but it is a black box. So some minimal
protection is possible :)

Pavel

> Joshua D. Drake
>
>>
>
> --
> PostgreSQL.org Major Contributor
> Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
> Consulting, Training, Support, Custom Development, Engineering
>
>

On Thu, Jun 24, 2010 at 10:20 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> On Thu, 2010-06-24 at 22:18 +0100, Dave Page wrote:
>
>> > I have no problem with him trying to protect his hard earned work. I
>> > just think he is trying to solve the wrong problem.
>>
>> It's a real problem faced by many businesses and solved by most
>> commercial DBMSs. Of course, it's basically impossible to solve in the
>> Open Source world, as there's nowhere to hide a key or obfuscation
>> algorithm. If akp geek is able to use EnterpriseDB builds of Postgres,
>> then he may want to look at PL/Secure, which will obfuscate his
>> pl/pgsql code:
>>
>> http://www.enterprisedb.com/products/pl_secure_standard_server.do
>
> That's interesting... does it just turn it into bytecode?

No, it runs it through a few different obfuscation algorithms to make
it very difficult to decode without knowledge of them.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

On Fri, Jun 25, 2010 at 12:28 AM, Dave Page <dpage@pgadmin.org> wrote:
> On Thu, Jun 24, 2010 at 10:20 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
>> On Thu, 2010-06-24 at 22:18 +0100, Dave Page wrote:
>>
>>> > I have no problem with him trying to protect his hard earned work. I
>>> > just think he is trying to solve the wrong problem.
>>>
>>> It's a real problem faced by many businesses and solved by most
>>> commercial DBMSs. Of course, it's basically impossible to solve in the
>>> Open Source world, as there's nowhere to hide a key or obfuscation
>>> algorithm. If akp geek is able to use EnterpriseDB builds of Postgres,
>>> then he may want to look at PL/Secure, which will obfuscate his
>>> pl/pgsql code:
>>>
>>> http://www.enterprisedb.com/products/pl_secure_standard_server.do
>>
>> That's interesting... does it just turn it into bytecode?
>
> No, it runs it through a few different obfuscation algorithms to make
> it very difficult to decode without knowledge of them.
>
> --
> Dave Page
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise Postgres Company
>

Perhaps (I could be wrong here), there may be a way (even though I
don't really support the obfuscation, vendor lockup etc... idea).
1)Use a commercial DB (as mentioned previously), they seem to have
provided for this.
2)Use PostgreSQL and write all code into C functions and complied to a
given PostgreSQL installation.


Allan.

On Thu, Jun 24, 2010 at 10:59 PM, Allan Kamau <kamauallan@gmail.com> wrote:

> Perhaps (I could be wrong here), there may be a way (even though I
> don't really support the obfuscation, vendor lockup etc... idea).
> 1)Use a commercial DB (as mentioned previously), they seem to have
> provided for this.
> 2)Use PostgreSQL and write all code into C functions and complied to a
> given PostgreSQL installation.

You could do that. It's not exactly productive to write/rewrite all
your functions in C if pl/pgsql will work though, plus it means you
need to compile separate binaries for each for each platform your
customers use, and upgrades can no longer be pure SQL scripts, as
you'll also need to ship new object files and install them on the
database server.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

On Thu, 2010-06-24 at 16:06 -0400, akp geek wrote:
> It's not for the user postgres.. If I have created a testuser, can I
> hide the code for that testuser?

No. Of course you have to wonder, "why" you would do that. It is the
data you are protecting, not the code to retrieve the data. Just make
sure they don't have access to the data.

Joshua D. Drake



--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering

On Fri, 2010-06-25 at 00:00 +0300, Allan Kamau wrote:

>
> Seems akp would like to hide/protect (including his name) his hard
> earned code/IP which may have consumed some man-hours, which to run,
> requires well built and generously given PostgreSQL code which has
> taken man-decades to develop.
>

I have no problem with him trying to protect his hard earned work. I
just think he is trying to solve the wrong problem.

Joshua D. Drake

> Allan.
>

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering

On Thu, 2010-06-24 at 22:18 +0100, Dave Page wrote:

> > I have no problem with him trying to protect his hard earned work. I
> > just think he is trying to solve the wrong problem.
>
> It's a real problem faced by many businesses and solved by most
> commercial DBMSs. Of course, it's basically impossible to solve in the
> Open Source world, as there's nowhere to hide a key or obfuscation
> algorithm. If akp geek is able to use EnterpriseDB builds of Postgres,
> then he may want to look at PL/Secure, which will obfuscate his
> pl/pgsql code:
>
> http://www.enterprisedb.com/products/pl_secure_standard_server.do

That's interesting... does it just turn it into bytecode?

Joshua D. Drake

>

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering