Re: securing pg_proc - Mailing list pgsql-hackers

From Tom Lane
Subject Re: securing pg_proc
Date
Msg-id 25331.1111080212@sss.pgh.pa.us
Whole thread Raw
In response to Re: securing pg_proc  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
List pgsql-hackers
"Merlin Moncure" <merlin.moncure@rcsonline.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


pgsql-hackers by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: securing pg_proc
Next
From: Bruce Momjian
Date:
Subject: Re: Changing the default wal_sync_method to open_sync for