Re: Granting control of SUSET gucs to non-superusers

Поиск
Список
Период
Сортировка
От Chapman Flack
Тема Re: Granting control of SUSET gucs to non-superusers
Дата
Msg-id 608D83BC.7060101@anastigmatix.net
обсуждение исходный текст
Ответ на Re: Granting control of SUSET gucs to non-superusers  (Mark Dilger <mark.dilger@enterprisedb.com>)
Ответы Re: Granting control of SUSET gucs to non-superusers  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 05/01/21 12:13, Mark Dilger wrote:
> Extra syntax for use by the service provider seems much easier to justify.
> 
> If the service provider can install extra role-aware check_hooks for gucs,
> and if the include directive for postgresql.conf can specify a role under
> which a postgresql.conf.tenant file is processed, then the tenant can port
> their application and their config file and the only things that should break
> are those things the provider has intentionally prohibited.

Maybe version 0 is where the provider just builds a shared object
to go in shared_preload_libraries. The provider has probably already
done a bunch of other stuff more challenging than that.

The GUC system would have to expose a way for the shared object to
chain extra_check_hooks off existing GUCs. An extra_check_hook can check
both the value and the role of the caller.

The configfile syntax for include-with-a-role would be the only other
missing piece.

Version 0.5 is maybe where someone contributes code for such a shared
object that is somewhat general and configured by a yaml file, or
something. (That would probably be easier if an extra_check_hook accepts
the usual void *extra context argument that existing GUC hooks don't.)

Regards,
-Chap



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

Предыдущее
От: Zhihong Yu
Дата:
Сообщение: Re: Transactions involving multiple postgres foreign servers, take 2
Следующее
От: Zhihong Yu
Дата:
Сообщение: Re: Dump public schema ownership & seclabels