pg_parameter_aclcheck() and trusted extensions
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
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
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
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
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
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
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:
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
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
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
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
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
Attachments:
fix-guc-permissions-checking-1.patchtext/x-diff; charset=us-ascii; name=fix-guc-permissions-checking-1.patchDownload+217-51
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
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
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
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
Attachments:
fix_reset_all_for_gucs.patchtext/x-diff; charset=us-asciiDownload+4-1
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
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