Re: securing pg_proc

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: "List pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: securing pg_proc
Date: 2005-03-17 17:23:32
Message-ID: 25331.1111080212@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:
> However, I'm a little unclear about where you stand on the relative
> merit (whatever the implementation) of hiding at the very least prosrc
> from non-priv users.

OK, in words of one syllable: I'm agin it.

I think your proposal is a hack that solves one aspect of the general
schema-info-protection problem, for just one category of requirements,
and it does so in an intrusive and expensive fashion that will be a
permanent backwards-compatibility problem whenever someone comes up
with a more general solution. (Sooner or later, someone probably
will, because we hear requests for this kind of thing often enough.)
Also, it imposes the policy, the runtime cost to enforce the policy,
and the compatibility issues on everyone whether they want that policy
or not.

There are other ways to solve it that have fewer side-effects. For
instance you could imagine inventing a new PL "plprotected" in which
the prosrc entry is a reference to some row in another table. The PL
just fetches the function body from that table and passes it off to the
"real" PL. (A possible variant: the function body stays in prosrc, but
is encrypted.) This approach makes the feature optional and imposes its
costs only on those who want to pay them.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-03-17 17:30:37 Re: Changing the default wal_sync_method to open_sync for
Previous Message Merlin Moncure 2005-03-17 16:50:21 Re: securing pg_proc