Обсуждение: Hide the code from users postgres
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?
Regards
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
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:
Hello
2010/6/24 akp geek <akpgeek@gmail.com>:> Hi all -you can't do it for user postgres.
> Is there way in postgres to set the user privileges so that when
> they login , the user can not see functions and views?
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
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:
On Thu, Jun 24, 2010 at 10:59 PM, Allan Kamau <kamauallan@gmail.com> wrote:You could do that. It's not exactly productive to write/rewrite all
> 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.
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.
----
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
He asked a legitimate question. Why he wants to hide the code is his business. If you don't know the answer, or don't want to tell him, don't answer.
Michael Milligan