Re: Oracle and Postgresql - Mailing list pgsql-general

From Scott Marlowe
Subject Re: Oracle and Postgresql
Date
Msg-id dcc563d10809151315g4aef389awd94b21c79f3daa3a@mail.gmail.com
Whole thread Raw
In response to Re: Oracle and Postgresql  (Christophe <xof@thebuild.com>)
Responses Re: Oracle and Postgresql  (Christophe <xof@thebuild.com>)
Re: Oracle and Postgresql  ("Roberts, Jon" <Jon.Roberts@asurion.com>)
Re: Oracle and Postgresql  (Casey Allen Shobe <cshobe@bepress.com>)
List pgsql-general
On Mon, Sep 15, 2008 at 2:04 PM, Christophe <xof@thebuild.com> wrote:
>
> On Sep 15, 2008, at 12:56 PM, Scott Marlowe wrote:
>>
>> I could totally get behind needing permission to see the plpgsql code.
>
> :)

I wasn't kidding up there.  Setting view permissions on plpgsql (or
any pl code really) would be understandable.  If you're not a super
user or the owner, you need permission to see it.

> More seriously, this is the issue with code-encryption on an open source
> platform: Where do you keep the key?  From my (admittedly brief) research,
> it appears that Oracle bakes it into the server binary, which isn't going to
> work for PG.  It sounds like a separate, binary-only plug-in that takes the
> encrypted procedure, decrypts it, and passes it on to PL/pgSQL for execution
> is the best bet, if this is really a critical feature for someone.

But whether it's oracle or postgresql, this is just security through
obscurity. If you have root access on the server either method would
be trivial to hack.  anyone who's used a debugger with stop points
could hack the binary only oracle or postgresql.

A lot of people think binary only is some kind of magic pixie dust
that keeps people from seeing what the code's doing.  modern
disassemblers and debuggers make figuring out binaries pretty simple.

My point being that encrypting plsql or plpgsql is really just smoke
and mirrors.

pgsql-general by date:

Previous
From: Christophe
Date:
Subject: Re: Oracle and Postgresql
Next
From: Devrim GÜNDÜZ
Date:
Subject: Re: Oracle and Postgresql