Re: crypting prosrc in pg_proc - Mailing list pgsql-hackers

From Hans-Juergen Schoenig
Subject Re: crypting prosrc in pg_proc
Date
Msg-id C719AE8A-28F0-454A-90F4-9C1084BA1445@cybertec.at
Whole thread Raw
In response to Re: crypting prosrc in pg_proc  ("korry.douglas" <korry.douglas@enterprisedb.com>)
Responses Re: crypting prosrc in pg_proc  (Hannu Krosing <hannu@skype.net>)
List pgsql-hackers

On Aug 9, 2007, at 4:47 PM, korry.douglas wrote:


the idea is basically to hide codes - many companies want that and ask for it again and again.
Hide code from who (or is that whom?)? 


the code should be hidden from the guy who is actually executing the function.
so:
some user is doing: select func();

the backend loads the keys from PGDATA, decrypts the codes executes them. as a normal user cannot look "into" the backend the code is safe.
the keys are only visible to the sysadmis but not at SQL level.



The PL compiler(s) will need to decrypt the code. 


no, the backend will pass the decrypted codes to the call handler.
there is no need for Perl, Python or so to be aware of this issue.


If a compiler can decrypt it, then anyone can decrypt it (because the compilers are open-source). 
And the problem is that any user that can run a function must be able to compile that function, and therefore, any user that can run a function must have the decryption key for that function.  So, I'm not sure you've secured the source code from any user that can run the function.


why that? the backend is doing the job. the user does not pass the keys. it is a database internal thing. the only idea is to make sure that pg_proc does not contain user readable code.



Of course, if your goal is to hide the code from someone snooping through the pg_proc relation (on disk), then encryption will certainly help (provided the key is properly protected).



no, somebody who has access to the filesystem is not relevant.
just think of shipping some database inside some router or inside some other stuff. the vendor just wants to make sure that other people don't fully understand the "magic" going on.

hans


--
Cybertec Geschwinde & Schönig GmbH
Gröhrmühlgasse 26, 2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at


pgsql-hackers by date:

Previous
From: Decibel!
Date:
Subject: Re: GUC for default heap fillfactor
Next
From: Greg Smith
Date:
Subject: Re: crypting prosrc in pg_proc