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

It's not for the user postgres.. If I have created a testuser, can I hide
the code for that testuser?

Regards

On Thu, Jun 24, 2010 at 3:42 PM, Pavel Stehule <pavel.stehule@gmail.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

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 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 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, 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

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, 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 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

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

Thank you all for the responses. I got a requirement from my boss that I
need to give read only access to only tables , so that users can write some
queries. At that time, he also mentioned that the users should not see the
code. I read the document , but not able to figure out how to do that and
then posted the question for the help.

Regards

On Thu, Jun 24, 2010 at 6:04 PM, Dave Page <dpage@pgadmin.org> wrote: