Re: viewing source code

It seems like a lot of people only saw "hide source code" in the
original message, and then went off on tangents that don't have
anything to do with the request.

Again:

On 12/14/07, Roberts, Jon <Jon.Roberts@asurion.com> wrote:
> Is it possible yet in PostgreSQL to hide the source code of functions from
> users based on role membership?  I would like to avoid converting the code
> to C to secure the source code and I don't want it obfuscated either.
>
> In an ideal world, if a user can't modify a function, he/she shouldn't be
> able to see the source code.  If the user can execute the function, then the
> user should be able to see the signature of the function but not the body.

As a Role under PostgreSQL, I can create tables, views, functions,
etc. As the owner of those objects, I can control what other roles can
view data through them, and what roles can modify them.

However, unlike tables, I cannot control what roles can view the data
contained within my PL functions (body).

That's it. A very simple problem. One that has absolutely nothing
whatsoever to do with encrypted storage on disk or hiding things from
DBAs or superusers.

I'm surprised this group ended up so far off point. It's not as if
objecting to this requires a bunch of abstract hyperbole, just a
simple "it's not worth the effort and it's considered a bad idea to
put security-senstive data inside PL function bodies".


On 12/20/07, Joshua D. Drake <jd@commandprompt.com> wrote:
> On Thu, 20 Dec 2007 10:47:53 -0800
> "Trevor Talbot" <quension@gmail.com> wrote:

> > > This "feature" as it is called can be developed externally and has
> > > zero reason to exist within PostgreSQL. If the feature has the
> > > level of demand that people think that it does, then the external
> > > project will be very successful and that's cool.

> > I'm unsure of what you consider "external" here. Is SE-PostgreSQL the
> > type of thing you mean?

> I don't know that it needs to be that extensive. I noted elsewhere in
> the thread the idea of a plpgsql_s. I think that is an interesting
> idea. I just don't think it needs to be incorporated into
> postgresql-core.

I was trying to get a handle on whether you meant external as in
middleware, or external as in third-party patches to PostgreSQL. The
OP's request doesn't necessarily need something as extensive as
SE-PostgreSQL, but it needs to be on the same level: something that
affects the database surface clients see, not apps behind middleware.


On 12/20/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Merlin Moncure" <mmoncure@gmail.com> writes:

> > I don't really agree that wrapping pl/pgsql with encryptor/decryptor
> > is a bad idea.

> It's quite a good idea, because it has more than zero chance of
> succeeding politically in the community.

Something that looks a lot like encryption of the entire database is
more likely to succeed politically than a simple addition to
PostgreSQL's existing role-based security model? Really?

It's not like I can claim otherwise, I'm just wondering if I woke up
in an alternate universe this morning...

> The fundamental reason why preventing access to pg_proc.prosrc won't
> happen is this: all the pain (and there will be plenty) will be
> inflicted on people who get none of the benefit (because they don't give
> a damn about hiding their own functions' code).  The folks who want
> function hiding can shout all they want, but as long as there is a very
> sizable fraction of the community who flat out *don't* want it, it's
> not going to get applied.

I don't understand. Can you give an example of pain you see coming?