Re: Hiding PG/SQL functions - Mailing list pgsql-admin

From Andrew Sullivan
Subject Re: Hiding PG/SQL functions
Date
Msg-id 20080408142011.GB8310@crankycanuck.ca
Whole thread Raw
In response to Hiding PG/SQL functions  (biggero@poczta.onet.pl)
List pgsql-admin
On Tue, Apr 08, 2008 at 12:25:03PM +0200, biggero@poczta.onet.pl wrote:
>
> My questions are:

> 1. How can you hide PG/SQL functions from other users, so that they can't
> see the functions, but they can still execute them?

See the archives on this.  There are some tricks suggested, but the short
answer is, "You can't."

> 2. What do you think about this idea: Can you embed PG/SQL function in a C
> code, compile it to a shared library and then let the users use it? How do
> you do that?  This would protect my functions (I think). I would rather
> not give up PG/SQL language as the procedures are almost ready. So
> embedding PG/SQL in C is feasible, while writing all procedures from the
> scratch rather not.

I don't know what it would mean to embed them in C code: you'd have to write
enough C that you might as well just port the functions completely.

> 3. Where can I find more details about database security in this respect
> (ie. protection of my code). Even some links to the manual would be
> helpful.

Well, to begin with, you can do a quick search for "Security by obscurity,"
where you will likely discover that this is no kind of security at all (not
even, really, protection of your code: it'd be fairly trivial even if you
could obscure your functions to find out what they're doing, by looking at
the logs of the database back end).  Unless you run everything for the users
and control where the code is installed and how it is distributed, some
people will almost certainly attempt to do something with your code that you
don't want them doing (as just about every software vendor has re-learned
for themselves).

Best,

A


pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: cannot restore a view after a dump
Next
From: "Tena Sakai"
Date:
Subject: Re: Handling large volumes of data