On Tue, Jul 19, 2022 at 04:27:08PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> However, I wonder if a
>> better way to fix this is to provide a way to stop set_config_option() from
>> throwing errors (e.g., setting elevel to -1). That way, we could remove
>> the manual permissions checks i
Nathan Bossart writes:
>> I think this is because GUCArrayReset() is the only caller of
>> validate_option_array_item() that sets skipIfNoPermissions to true. The
>> others fall through to set_config_option(), which does a
>> pg_parameter_aclcheck(). So, you are right.
> Here's a small patch th
On Thu, Jul 14, 2022 at 03:57:35PM -0700, Nathan Bossart wrote:
> However, ALTER ROLE RESET ALL will be blocked, while resetting only the
> individual GUC will go through.
>
> postgres=> ALTER ROLE other RESET ALL;
> ALTER ROLE
> postgres=> SELECT * FROM pg_db_role_setting;
>
On Thu, Jul 14, 2022 at 06:03:45PM -0400, Tom Lane wrote:
> Nathan Bossart 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 permiss
Nathan Bossart 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
>> permissio
On Thu, Jul 14, 2022 at 04:02:30PM -0400, Tom Lane wrote:
> Here's a draft patch for that. I initially ran around and changed all
> the set_config_option callers as I threatened before, but as I did it
> I could not help observing that they were all changing in exactly the
> same way: basically, t
I wrote:
> Michael Paquier writes:
>> Looks like a bug to me, so I have added an open item assigned to Tom.
> Yeah. So the fix here seems pretty obvious: rather than applying the
> permissions check using bare GetUserId(), we need to remember the role
> OID that originally applied the setting, a
John Naylor writes:
> The RMT has discussed this item further, and we agree an ABI break is
> acceptable for resolving this issue.
Cool, I'll produce a patch soon.
regards, tom lane
On Fri, Jul 8, 2022 at 1:09 PM Michael Paquier wrote:
>
> On Thu, Jul 07, 2022 at 03:43:03PM -0400, Joe Conway wrote:
> > On 7/7/22 15:00, Tom Lane wrote:
> >> The aspect that is a bit more debatable is whether to trouble with
> >> a set_config_option() wrapper to avoid the API break in v15.
> >>
On Thu, Jul 07, 2022 at 03:43:03PM -0400, Joe Conway wrote:
> On 7/7/22 15:00, Tom Lane wrote:
>> The aspect that is a bit more debatable is whether to trouble with
>> a set_config_option() wrapper to avoid the API break in v15.
>> I think we'd still be making people deal with an API break in v16,
On 7/7/22 15:00, Tom Lane wrote:
Nathan Bossart writes:
On Thu, Jul 07, 2022 at 12:41:00PM -0400, Tom Lane wrote:
Can we get away with doing these things in beta3? We could avoid
breaking (2) in the v15 branch by making set_config_option into
a wrapper around set_config_option_ext, or somethi
Nathan Bossart writes:
> On Thu, Jul 07, 2022 at 12:41:00PM -0400, Tom Lane wrote:
>> Can we get away with doing these things in beta3? We could avoid
>> breaking (2) in the v15 branch by making set_config_option into
>> a wrapper around set_config_option_ext, or something like that;
>> but the p
On Thu, Jul 07, 2022 at 12:41:00PM -0400, Tom Lane wrote:
> Yeah. So the fix here seems pretty obvious: rather than applying the
> permissions check using bare GetUserId(), we need to remember the role
> OID that originally applied the setting, and use that.
Please ignore my previous message. Th
On Thu, Jul 07, 2022 at 10:04:18AM +0900, Michael Paquier wrote:
> On Wed, Jul 06, 2022 at 03:47:27PM -0700, Nathan Bossart wrote:
>> I think the call to superuser_arg() in pg_parameter_aclmask() is causing
>> set_config_option() to bypass the normal privilege checks, as
>> execute_extension_script
Michael Paquier writes:
> On Wed, Jul 06, 2022 at 03:47:27PM -0700, Nathan Bossart wrote:
>> I think the call to superuser_arg() in pg_parameter_aclmask() is causing
>> set_config_option() to bypass the normal privilege checks, as
>> execute_extension_script() will have set the user ID to the boot
On Wed, Jul 06, 2022 at 03:47:27PM -0700, Nathan Bossart wrote:
> I think the call to superuser_arg() in pg_parameter_aclmask() is causing
> set_config_option() to bypass the normal privilege checks, as
> execute_extension_script() will have set the user ID to the bootstrap
> superuser for trusted
16 matches
Mail list logo
