Re: pg_parameter_aclcheck() and trusted extensions
От | Tom Lane |
---|---|
Тема | Re: pg_parameter_aclcheck() and trusted extensions |
Дата | |
Msg-id | 3159281.1657836225@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_parameter_aclcheck() and trusted extensions (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: pg_parameter_aclcheck() and trusted extensions
|
Список | pgsql-hackers |
Nathan Bossart <nathandbossart@gmail.com> writes: > On Thu, Jul 14, 2022 at 04:02:30PM -0400, Tom Lane wrote: >> I noted something that ought to be looked at separately: >> validate_option_array_item() seems like it needs to be taught about >> grantable permissions on GUCs. I think that right now it may report >> permissions failures in some cases where it should succeed. > Which cases do you think might be inappropriately reporting permissions > failures? It looked to me like this stuff was mostly used for > pg_db_role_setting, which wouldn't be impacted by the current set of > grantable GUC permissions. Is the idea that you should be able to do ALTER > ROLE SET for GUCs that you have SET permissions for? Well, that's what I'm wondering. Obviously that wouldn't *alone* be enough permissions, but it seems like it could be a component of it. Specifically, this bit: /* manual permissions check so we can avoid an error being thrown */ if (gconf->context == PGC_USERSET) /* ok */ ; else if (gconf->context == PGC_SUSET && superuser()) /* ok */ ; else if (skipIfNoPermissions) return false; seems like it's trying to duplicate what set_config_option would do, and it's now missing a component of that. If it shouldn't check per-GUC permissions along with superuser(), we should add a comment explaining why not. regards, tom lane
В списке pgsql-hackers по дате отправления: