Re: crypting prosrc in pg_proc

From: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>
To: "korry(dot)douglas" <korry(dot)douglas(at)enterprisedb(dot)com>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: crypting prosrc in pg_proc
Date: 2007-08-09 14:54:33
Message-ID: C719AE8A-28F0-454A-90F4-9C1084BA1445@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2007-08-09 15:03:22 Re: crypting prosrc in pg_proc
Previous Message Decibel! 2007-08-09 14:53:24 Re: GUC for default heap fillfactor