Horton

Thread

Commits

  1. Fix missed corner cases for grantable permissions on GUCs.

  1. pg_parameter_aclcheck() and trusted extensions

    Nathan Bossart <nathandbossart@gmail.com> — 2022-07-06T22:47:27Z

    Hi hackers,

I found that as of a0ffa88, it's possible to set a PGC_SUSET GUC defined by
a trusted extension as a non-superuser.  I've confirmed that this only
affects v15 and later versions.

	postgres=# CREATE ROLE testuser;
	CREATE ROLE
	postgres=# GRANT CREATE ON DATABASE postgres TO testuser;
	GRANT
	postgres=# SET ROLE testuser;
	SET
	postgres=> SET plperl.on_plperl_init = 'test';
	SET
	postgres=> CREATE EXTENSION plperl;
	CREATE EXTENSION
	postgres=> SELECT setting FROM pg_settings WHERE name = 'plperl.on_plperl_init';
	 setting 
	---------
	 test
	(1 row)

On previous versions, the CREATE EXTENSION command emits the following
WARNING, and the setting does not take effect:

	WARNING:  permission denied to set parameter "plperl.on_plperl_init"

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 extensions like plperl.  I don't have a patch or a
proposal at the moment, but I thought it was worth starting the discussion.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

  2. Re: pg_parameter_aclcheck() and trusted extensions

    Michael Paquier <michael@paquier.xyz> — 2022-07-07T01:04:18Z

    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 extensions like plperl.  I don't have a patch or a
> proposal at the moment, but I thought it was worth starting the discussion.

Looks like a bug to me, so I have added an open item assigned to Tom.
--
Michael

  3. Re: pg_parameter_aclcheck() and trusted extensions

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-07-07T16:41:00Z

    Michael Paquier <michael@paquier.xyz> 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 bootstrap
>> superuser for trusted extensions like plperl.  I don't have a patch or a
>> proposal at the moment, but I thought it was worth starting the discussion.

> 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, and use that.

The problem with this sketch is that

(1) we need an OID field in struct config_generic, as well as GucStack,
which means an ABI break for any extensions that look directly at GUC
records.  There probably aren't many, but ...

(2) we need an additional parameter to set_config_option, which
again is a compatibility break for anything calling that directly.
There surely are such callers --- our own extensions do it.

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 problem with struct config_generic seems inescapable.
(Putting the new field at the end would solve nothing, since
config_generic is embedded into larger structs.)

The alternative to API/ABI breaks seems to be to revert the
feature, which would be sad.

			regards, tom lane

  4. Re: pg_parameter_aclcheck() and trusted extensions

    Nathan Bossart <nathandbossart@gmail.com> — 2022-07-07T16:49:21Z

    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() will have set the user ID to the bootstrap
>> superuser for trusted extensions like plperl.  I don't have a patch or a
>> proposal at the moment, but I thought it was worth starting the discussion.
> 
> Looks like a bug to me, so I have added an open item assigned to Tom.

Thanks.  I've been thinking about this one a bit.  For simple cases like
plperl, it would be easy enough to temporarily revert the superuser switch
when calling _PG_init() or one of the DefineCustomXXXVariable functions.
Unfortunately, I think there are more complicated scenarios.  For example,
what role should pg_parameter_aclmask() use when a trusted extension script
loads a library after SET ROLE?  The original user might not ordinarily be
able to assume this role, so the trusted extension script could still be a
way to set parameters you don't have privileges for.  Should we just always
use the role that's calling CREATE EXTENSION?

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

  5. Re: pg_parameter_aclcheck() and trusted extensions

    Nathan Bossart <nathandbossart@gmail.com> — 2022-07-07T18:40:01Z

    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.  This makes sense.

> The problem with this sketch is that
> 
> (1) we need an OID field in struct config_generic, as well as GucStack,
> which means an ABI break for any extensions that look directly at GUC
> records.  There probably aren't many, but ...
> 
> (2) we need an additional parameter to set_config_option, which
> again is a compatibility break for anything calling that directly.
> There surely are such callers --- our own extensions do it.
> 
> 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 problem with struct config_generic seems inescapable.
> (Putting the new field at the end would solve nothing, since
> config_generic is embedded into larger structs.)
> 
> The alternative to API/ABI breaks seems to be to revert the
> feature, which would be sad.

I personally lean more towards the compatibility break than reverting the
feature.  There are still a couple of months before 15.0, and I suspect it
won't be too difficult to fix any extensions that break because of this.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

  6. Re: pg_parameter_aclcheck() and trusted extensions

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-07-07T19:00:09Z

    Nathan Bossart <nathandbossart@gmail.com> 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 problem with struct config_generic seems inescapable.

> I personally lean more towards the compatibility break than reverting the
> feature.  There are still a couple of months before 15.0, and I suspect it
> won't be too difficult to fix any extensions that break because of this.

I checked http://codesearch.debian.net and found only a couple of
extensions that #include guc_tables.h at all, so I'm satisfied
that the struct config_generic ABI issue is tolerable.  Recompiling
after beta3 would be enough to fix any problem there, and it's
hard to believe that anyone is trying to ship production-ready
v15 extensions already.

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,
so making them do it this year rather than next doesn't seem like
a big deal ... but maybe someone wants to argue it's too late
for API breaks in v15?

			regards, tom lane

  7. Re: pg_parameter_aclcheck() and trusted extensions

    Joe Conway <mail@joeconway.com> — 2022-07-07T19:43:03Z

    On 7/7/22 15:00, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> 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 problem with struct config_generic seems inescapable.
> 
>> I personally lean more towards the compatibility break than reverting the
>> feature.  There are still a couple of months before 15.0, and I suspect it
>> won't be too difficult to fix any extensions that break because of this.
> 
> I checked http://codesearch.debian.net and found only a couple of
> extensions that #include guc_tables.h at all, so I'm satisfied
> that the struct config_generic ABI issue is tolerable.  Recompiling
> after beta3 would be enough to fix any problem there, and it's
> hard to believe that anyone is trying to ship production-ready
> v15 extensions already.

There are a handful here as well:

https://github.com/search?q=guc_tables.h+and+PG_MODULE_MAGIC&type=Code&ref=advsearch&l=&l=

But as one of the affected authors I would say recompiling after beta3 
is fine.

> 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,
> so making them do it this year rather than next doesn't seem like
> a big deal ... but maybe someone wants to argue it's too late
> for API breaks in v15?

Well there are other API breaks that affect me in v15, and to be honest 
I have done little except keep an eye out for the ones likely to affect 
extensions I maintain so far, so may as well inflict the pain now as 
later ¯\_(ツ)_/¯

Joe
-- 
Joe Conway
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

  8. Re: pg_parameter_aclcheck() and trusted extensions

    Michael Paquier <michael@paquier.xyz> — 2022-07-08T06:09:17Z

    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,
>> so making them do it this year rather than next doesn't seem like
>> a big deal ... but maybe someone wants to argue it's too late
>> for API breaks in v15?
> 
> Well there are other API breaks that affect me in v15, and to be honest I
> have done little except keep an eye out for the ones likely to affect
> extensions I maintain so far, so may as well inflict the pain now as later
> ¯\_(ツ)_/¯

With my RMT and hacker hat on, I see no reason to not break ABI or
APIs while we are still in beta, as long as the GA result is as best
as we can make it.  I have not looked at the reasoning behind the
issue, but if you think that this feature will work better in the long
term by having an extra field to track the role OID in one of the GUC
structs or in one of its API arguments, that's fine by me.

If this requires more work, a revert can of course be discussed, but I
am not getting that this is really necessary here.  This would be the
last option to consider.
--
Michael

  9. Re: pg_parameter_aclcheck() and trusted extensions

    John Naylor <john.naylor@enterprisedb.com> — 2022-07-14T04:48:35Z

    On Fri, Jul 8, 2022 at 1:09 PM Michael Paquier <michael@paquier.xyz> 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.
> >> I think we'd still be making people deal with an API break in v16,
> >> so making them do it this year rather than next doesn't seem like
> >> a big deal ... but maybe someone wants to argue it's too late
> >> for API breaks in v15?
> >
> > Well there are other API breaks that affect me in v15, and to be honest
I
> > have done little except keep an eye out for the ones likely to affect
> > extensions I maintain so far, so may as well inflict the pain now as
later
> > ¯\_(ツ)_/¯
>
> With my RMT and hacker hat on, I see no reason to not break ABI or
> APIs while we are still in beta, as long as the GA result is as best
> as we can make it.  I have not looked at the reasoning behind the
> issue, but if you think that this feature will work better in the long
> term by having an extra field to track the role OID in one of the GUC
> structs or in one of its API arguments, that's fine by me.
>
> If this requires more work, a revert can of course be discussed, but I
> am not getting that this is really necessary here.  This would be the
> last option to consider.

The RMT has discussed this item further, and we agree an ABI break is
acceptable for resolving this issue.

--
John Naylor
EDB: http://www.enterprisedb.com

  10. Re: pg_parameter_aclcheck() and trusted extensions

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-07-14T04:50:40Z

    John Naylor <john.naylor@enterprisedb.com> 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

  11. Re: pg_parameter_aclcheck() and trusted extensions

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-07-14T20:02:30Z

    I wrote:
> Michael Paquier <michael@paquier.xyz> 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, and use that.

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, they were passing GetUserId() if the GucContext
is PGC_S_SESSION and BOOTSTRAP_SUPERUSERID otherwise.  Not counting
guc.c internal call sites, there is a grand total of one caller that
fails to fit the pattern.  So that brought me around to liking the idea
of keeping set_config_option's API stable by making it a thin wrapper
around another function with an explicit role argument.  The result,
attached, poses far less of an API/ABI hazard than I was anticipating.
If you're not poking into the GUC tables you have little to fear.

Most of the bulk of this is mechanical changes to pass the source
role around properly in guc.c's data structures.  That's all basically
copy-and-paste from the code to track the source context (scontext).

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.

			regards, tom lane

  12. Re: pg_parameter_aclcheck() and trusted extensions

    Nathan Bossart <nathandbossart@gmail.com> — 2022-07-14T21:52:25Z

    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, they were passing GetUserId() if the GucContext
> is PGC_S_SESSION and BOOTSTRAP_SUPERUSERID otherwise.  Not counting
> guc.c internal call sites, there is a grand total of one caller that
> fails to fit the pattern.  So that brought me around to liking the idea
> of keeping set_config_option's API stable by making it a thin wrapper
> around another function with an explicit role argument.  The result,
> attached, poses far less of an API/ABI hazard than I was anticipating.
> If you're not poking into the GUC tables you have little to fear.
> 
> Most of the bulk of this is mechanical changes to pass the source
> role around properly in guc.c's data structures.  That's all basically
> copy-and-paste from the code to track the source context (scontext).

At first glance, this looks pretty reasonable to me.  

> 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?

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

  13. Re: pg_parameter_aclcheck() and trusted extensions

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-07-14T22:03:45Z

    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

  14. Re: pg_parameter_aclcheck() and trusted extensions

    Nathan Bossart <nathandbossart@gmail.com> — 2022-07-14T22:57:35Z

    On Thu, Jul 14, 2022 at 06:03:45PM -0400, Tom Lane wrote:
> 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.

I looked into this a bit closer.  I found that having SET permissions on a
GUC seems to allow you to ALTER ROLE SET it to others.

	postgres=# CREATE ROLE test CREATEROLE;
	CREATE ROLE
	postgres=# CREATE ROLE other;
	CREATE ROLE
	postgres=# GRANT SET ON PARAMETER zero_damaged_pages TO test;
	GRANT
	postgres=# SET ROLE test;
	SET
	postgres=> ALTER ROLE other SET zero_damaged_pages = 'on';
	ALTER ROLE
	postgres=> SELECT * FROM pg_db_role_setting;
	 setdatabase | setrole |        setconfig        
	-------------+---------+-------------------------
	           0 |   16385 | {zero_damaged_pages=on}
	(1 row)

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;
	 setdatabase | setrole |        setconfig        
	-------------+---------+-------------------------
	           0 |   16385 | {zero_damaged_pages=on}
	(1 row)

	postgres=> ALTER ROLE other RESET zero_damaged_pages;
	ALTER ROLE
	postgres=> SELECT * FROM pg_db_role_setting;
	 setdatabase | setrole | setconfig 
	-------------+---------+-----------
	(0 rows)

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.

Regarding whether SET privileges should be enough to allow ALTER ROLE SET,
I'm not sure I have an opinion yet.  You would need WITH GRANT OPTION to be
able to grant SET to that role, but that's a bit different than altering
the setting for the role.  You'll already have privileges to alter the role
(e.g., CREATEROLE), so requiring extra permissions to set GUCs on roles
feels like it might be excessive.  But there might be a good argument for
it.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

  15. Re: pg_parameter_aclcheck() and trusted extensions

    Nathan Bossart <nathandbossart@gmail.com> — 2022-07-18T21:56:49Z

    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;
> 	 setdatabase | setrole |        setconfig        
> 	-------------+---------+-------------------------
> 	           0 |   16385 | {zero_damaged_pages=on}
> 	(1 row)
> 
> 	postgres=> ALTER ROLE other RESET zero_damaged_pages;
> 	ALTER ROLE
> 	postgres=> SELECT * FROM pg_db_role_setting;
> 	 setdatabase | setrole | setconfig 
> 	-------------+---------+-----------
> 	(0 rows)
> 
> 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 that seems to fix this case.  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 in favor of always using the real ones, which
might help prevent similar bugs in the future.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

  16. Re: pg_parameter_aclcheck() and trusted extensions

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-07-19T20:27:08Z

    Nathan Bossart <nathandbossart@gmail.com> 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 that seems to fix this case.

Yeah, this is more or less what I was thinking of.

> 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 in favor of always using the real ones, which
> might help prevent similar bugs in the future.

I thought about that for a bit.  You could almost do it today if you
passed elevel == DEBUG5; the ensuing log chatter for failures would be
down in the noise compared to everything else you would see with
min_messages cranked down that far.  However,

(1) As things stand, set_config_option()'s result does not distinguish
no-permissions failures from other problems, so we'd need some rejiggering
of its API anyway.

(2) As you mused upthread, it's possible that ACL_SET isn't what we should
be checking here, but some more-specific privilege.  So I'd just as soon
keep this privilege check separate from set_config_option's.

I'll push ahead with fixing it like this.

			regards, tom lane

  17. Re: pg_parameter_aclcheck() and trusted extensions

    Nathan Bossart <nathandbossart@gmail.com> — 2022-07-19T21:41:42Z

    On Tue, Jul 19, 2022 at 04:27:08PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> 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 in favor of always using the real ones, which
>> might help prevent similar bugs in the future.
> 
> I thought about that for a bit.  You could almost do it today if you
> passed elevel == DEBUG5; the ensuing log chatter for failures would be
> down in the noise compared to everything else you would see with
> min_messages cranked down that far.  However,
> 
> (1) As things stand, set_config_option()'s result does not distinguish
> no-permissions failures from other problems, so we'd need some rejiggering
> of its API anyway.
> 
> (2) As you mused upthread, it's possible that ACL_SET isn't what we should
> be checking here, but some more-specific privilege.  So I'd just as soon
> keep this privilege check separate from set_config_option's.

I think we'd also need to keep the manual permissions checks for
placeholders, so it wouldn't save much, anyway.

> I'll push ahead with fixing it like this.

Sounds good.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com