Re: securing pg_proc

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: securing pg_proc
Дата
Msg-id 25331.1111080212@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: securing pg_proc  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
Список 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 по дате отправления:

Предыдущее
От: "Merlin Moncure"
Дата:
Сообщение: Re: securing pg_proc
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Changing the default wal_sync_method to open_sync for