Обсуждение: masking the code

I've wrote a PLPGSQL stored procedure for a DB I've to delivery to my
customer. The problem is that I want to hide the code of the stored
procedure. I don't want that my customer is able to read the code of the my
sp.

Do exist a way to mask the code of the store procedure shipped with my DB?

Thanks in advance.

Luca.
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f

 Sponsor:
 GRATIS: 250 Biglietti da Visita + 1 elegante Porta biglietti metallico!
Spese di spedizione escluse. Offerta limitata, fai in fretta!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8956&d=20090626

hello

2009/6/26  <luca.ciciriello@email.it>:
> I've wrote a PLPGSQL stored procedure for a DB I've to delivery to my
> customer. The problem is that I want to hide the code of the stored
> procedure. I don't want that my customer is able to read the code of the my
> sp.
>
> Do exist a way to mask the code of the store procedure shipped with my DB?
>

no - PostgreSQL doesn't support any form of obfuscation PL code. If
you have superuser rights on database - and your customer not, then
you can REVOKE SELECT right from pg_proc table.

regards
Pavel Stehule



> Thanks in advance.
>
> Luca.
>  --
>  Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
> autenticato? GRATIS solo con Email.it: http://www.email.it/f
>
>  Sponsor:
>  GRATIS: 250 Biglietti da Visita + 1 elegante Porta biglietti metallico!
> Spese di spedizione escluse. Offerta limitata, fai in fretta!
>  Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8956&d=20090626
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Luca, in addition to this:

that feature is on the "Features We Do Not Want " list of the
http://wiki.postgresql.org/wiki/Todo list:

Obfuscated function source code (not wanted) Obfuscating function source code has minimal protective benefits because anyone with super-user access can find a way to view the code. At the same time, it would greatly complicate backups and other administrative tasks. To prevent non-super-users from viewing function source code, remove SELECT permission on pg_proc.


best wishes,

HArald




--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
LASIK good, steroids bad?

On Fri, Jun 26, 2009 at 10:56:34AM +0200, luca.ciciriello@email.it wrote:
> I've wrote a PLPGSQL stored procedure for a DB I've to delivery to
> my customer. The problem is that I want to hide the code of the
> stored procedure. I don't want that my customer is able to read the
> code of the my sp.
>
> Do exist a way to mask the code of the store procedure shipped with
> my DB?

Others have pointed out that there isn't really, along with a bit of a
hack, which doesn't protect you from snooping into the procedure code
if the client has (or can get) database super-user access.

If you don't wish to expose this to clients, don't ship it to them.
If you wish to restrict clients' use of what you do ship them, the
appropriate place to do so is in the license and/or contract.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Hi,

Le 26 juin 09 à 10:56, luca.ciciriello@email.it a écrit :
> Do exist a way to mask the code of the store procedure shipped with
> my DB?

There's a way to do it which is not intended to cover this need: write
the procedure code in C, and only ship the .so and .sql, not the .c
code. You'll have to be superuser to load the C coded function, though.

But I don't see the point of hiding procedural code to your customer,
who's getting to see the database structure and data, I guess...

Regards,
--
dim

On Fri, Jun 26, 2009 at 1:37 PM, <artacus@comcast.net> wrote:
>
> Obfuscated function source code (not wanted) Obfuscating function source
> code has minimal protective benefits because anyone with super-user access
> can find a way to view the code. At the same time, it would greatly
> complicate backups and other administrative tasks. To prevent
> non-super-users from viewing function source code, remove SELECT permission
> on pg_proc.
>
>
> I completely agree w/ HArald. Its not something we'd want to see in an open
> source product. That said, I saw yesterday that the latest version of
> EnterpriseDB has this feature.  So if you want to protect your own IP, then
> you've got to purchase someone else's.

s/protect/pretend to protect/

On 2009-06-26, luca.ciciriello@email.it <luca.ciciriello@email.it> wrote:
> I've wrote a PLPGSQL stored procedure for a DB I've to delivery to my
> customer. The problem is that I want to hide the code of the stored
> procedure. I don't want that my customer is able to read the code of the my
> sp.
>
> Do exist a way to mask the code of the store procedure shipped with my DB?

rewrite it in a compiled language.

s/is declared/is NOT declared/g

:)

--
Jonah H. Harris, Senior DBA
myYearbook.com

Jasen Betts schrieb:

>> I've wrote a PLPGSQL stored procedure for a DB I've to delivery to my
>> customer. The problem is that I want to hide the code of the stored
>> procedure. I don't want that my customer is able to read the code of the my
>> sp.
>>
>> Do exist a way to mask the code of the store procedure shipped with my DB?
>
> rewrite it in a compiled language.

And hope, that the customer could not read the result.


Greetings,
Torsten

On Mon, Jun 29, 2009 at 2:31 PM, Scott Mead<scott.lists@enterprisedb.com> wrote:
> As with many different types of security (i.e. the 3 foot high fence) this
> is really just a deterrent to most people who either aren't capable of
> reverse engineering or are just not interested in the first place.

Someone I know used to work at a nuclear power and research facility
(No Dave, someone else) and told me an interesting story.

The facility in question was often beset by protesters who invariably
managed to scale the perimeter fence. He asked one of the security
guards one day why they didn't build a better fence since the
run-of-the-mill fence was obviously not up to the task for such a
large perimeter against determined foes.

The answer was that the fence was not there to keep people out at all.
It's purpose was in fact to ensure that when they prosecuted it would
be impossible for anyone to claim they hadn't realized they were
trespassing...


--
greg
http://mit.edu/~gsstark/resume.pdf

On Tue, Jun 30, 2009 at 4:40 AM, Greg Stark<gsstark@mit.edu> wrote:
> On Mon, Jun 29, 2009 at 2:31 PM, Scott Mead<scott.lists@enterprisedb.com> wrote:
>> As with many different types of security (i.e. the 3 foot high fence) this
>> is really just a deterrent to most people who either aren't capable of
>> reverse engineering or are just not interested in the first place.
>
> Someone I know used to work at a nuclear power and research facility
> (No Dave, someone else) and told me an interesting story.

Yet bizarrely it's almost identical in meaning to a story I did tell
you not so long ago...

(assuming you mean me of course!)

:-)

> The facility in question was often beset by protesters who invariably
> managed to scale the perimeter fence. He asked one of the security
> guards one day why they didn't build a better fence since the
> run-of-the-mill fence was obviously not up to the task for such a
> large perimeter against determined foes.
>
> The answer was that the fence was not there to keep people out at all.
> It's purpose was in fact to ensure that when they prosecuted it would
> be impossible for anyone to claim they hadn't realized they were
> trespassing...
>
>
> --
> greg
> http://mit.edu/~gsstark/resume.pdf
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>



--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com