Re: Restrict permissions on schema to hide pl/pgsql code

Поиск
Список
Период
Сортировка
От richard coleman
Тема Re: Restrict permissions on schema to hide pl/pgsql code
Дата
Msg-id CAGA3vBuMYQfN7oGb9uH4mU-jb-N10=oh1S6VTJuMOb_HPz3mFQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Restrict permissions on schema to hide pl/pgsql code  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Restrict permissions on schema to hide pl/pgsql code
Список pgsql-admin
I guess that just means postgresql probably shouldn't be used in a multi-tenancy situation if you need; 
  • complete isolation between tenants
  • you still want to give tenants direct and otherwise unfettered access to the database
just a thought, 

rik.

On Wed, Jul 24, 2019 at 1:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> You can consider this email to have accomplished both.  Lacking someone
> saying they they are working on it and pointing you to a patch you can
> safely operate under the assumption that this behavior isn’t going to
> change.

It isn't.  We've considered complaints like this before and determined
that we're not going to do anything about it.  For better or worse, the
PG catalogs are readable by any authorized user, with only narrow
exceptions (like password columns).

A sufficiently determined person could perhaps do something like creating
their own PL that stores encrypted function source text in pg_proc, and
just hands it off to an existing PL after decryption.  I'm not exactly
sure where you'd keep the decryption key though.

                        regards, tom lane


В списке pgsql-admin по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Restrict permissions on schema to hide pl/pgsql code
Следующее
От: Thomas Kellerer
Дата:
Сообщение: Re: Restrict permissions on schema to hide pl/pgsql code