public inbox for [email protected]help / color / mirror / Atom feed
pgsql: Require superuser to install a non-built-in selectivity estimato 6+ messages / 1 participants [nested] [flat]
* pgsql: Require superuser to install a non-built-in selectivity estimato @ 2026-02-09 15:15 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-09 15:15 UTC (permalink / raw) To: [email protected] Require superuser to install a non-built-in selectivity estimator. Selectivity estimators come in two flavors: those that make specific assumptions about the data types they are working with, and those that don't. Most of the built-in estimators are of the latter kind and are meant to be safely attachable to any operator. If the operator does not behave as the estimator expects, you might get a poor estimate, but it won't crash. However, estimators that do make datatype assumptions can malfunction if they are attached to the wrong operator, since then the data they get from pg_statistic may not be of the type they expect. This can rise to the level of a security problem, even permitting arbitrary code execution by a user who has the ability to create SQL objects. To close this hole, establish a rule that built-in estimators are required to protect themselves against being called on the wrong type of data. It does not seem practical however to expect estimators in extensions to reach a similar level of security, at least not in the near term. Therefore, also establish a rule that superuser privilege is required to attach a non-built-in estimator to an operator. We expect that this restriction will have little negative impact on extensions, since estimators generally have to be written in C and thus superuser privilege is required to create them in the first place. This commit changes the privilege checks in CREATE/ALTER OPERATOR to enforce the rule about superuser privilege, and fixes a couple of built-in estimators that were making datatype assumptions without sufficiently checking that they're valid. Reported-by: Daniel Firer as part of zeroday.cloud Author: Tom Lane <[email protected]> Reviewed-by: Noah Misch <[email protected]> Security: CVE-2026-2004 Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/bbf5bcf587bdd6f8fe446456fe3a515a00772f3c Modified Files -------------- src/backend/commands/operatorcmds.c | 57 +++++++++++++++++++++++++------- src/backend/tsearch/ts_selfuncs.c | 8 +++-- src/backend/utils/adt/network_selfuncs.c | 48 ++++++++++++++++++--------- 3 files changed, 83 insertions(+), 30 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Require superuser to install a non-built-in selectivity estimato @ 2026-02-09 15:15 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-09 15:15 UTC (permalink / raw) To: [email protected] Require superuser to install a non-built-in selectivity estimator. Selectivity estimators come in two flavors: those that make specific assumptions about the data types they are working with, and those that don't. Most of the built-in estimators are of the latter kind and are meant to be safely attachable to any operator. If the operator does not behave as the estimator expects, you might get a poor estimate, but it won't crash. However, estimators that do make datatype assumptions can malfunction if they are attached to the wrong operator, since then the data they get from pg_statistic may not be of the type they expect. This can rise to the level of a security problem, even permitting arbitrary code execution by a user who has the ability to create SQL objects. To close this hole, establish a rule that built-in estimators are required to protect themselves against being called on the wrong type of data. It does not seem practical however to expect estimators in extensions to reach a similar level of security, at least not in the near term. Therefore, also establish a rule that superuser privilege is required to attach a non-built-in estimator to an operator. We expect that this restriction will have little negative impact on extensions, since estimators generally have to be written in C and thus superuser privilege is required to create them in the first place. This commit changes the privilege checks in CREATE/ALTER OPERATOR to enforce the rule about superuser privilege, and fixes a couple of built-in estimators that were making datatype assumptions without sufficiently checking that they're valid. Reported-by: Daniel Firer as part of zeroday.cloud Author: Tom Lane <[email protected]> Reviewed-by: Noah Misch <[email protected]> Security: CVE-2026-2004 Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/91d7c0bfdd4ae1da0aa3946e35eb1327b5ca2e6d Modified Files -------------- src/backend/commands/operatorcmds.c | 57 +++++++++++++++++++++++++------- src/backend/tsearch/ts_selfuncs.c | 8 +++-- src/backend/utils/adt/network_selfuncs.c | 48 ++++++++++++++++++--------- 3 files changed, 83 insertions(+), 30 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Require superuser to install a non-built-in selectivity estimato @ 2026-02-09 15:15 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-09 15:15 UTC (permalink / raw) To: [email protected] Require superuser to install a non-built-in selectivity estimator. Selectivity estimators come in two flavors: those that make specific assumptions about the data types they are working with, and those that don't. Most of the built-in estimators are of the latter kind and are meant to be safely attachable to any operator. If the operator does not behave as the estimator expects, you might get a poor estimate, but it won't crash. However, estimators that do make datatype assumptions can malfunction if they are attached to the wrong operator, since then the data they get from pg_statistic may not be of the type they expect. This can rise to the level of a security problem, even permitting arbitrary code execution by a user who has the ability to create SQL objects. To close this hole, establish a rule that built-in estimators are required to protect themselves against being called on the wrong type of data. It does not seem practical however to expect estimators in extensions to reach a similar level of security, at least not in the near term. Therefore, also establish a rule that superuser privilege is required to attach a non-built-in estimator to an operator. We expect that this restriction will have little negative impact on extensions, since estimators generally have to be written in C and thus superuser privilege is required to create them in the first place. This commit changes the privilege checks in CREATE/ALTER OPERATOR to enforce the rule about superuser privilege, and fixes a couple of built-in estimators that were making datatype assumptions without sufficiently checking that they're valid. Reported-by: Daniel Firer as part of zeroday.cloud Author: Tom Lane <[email protected]> Reviewed-by: Noah Misch <[email protected]> Security: CVE-2026-2004 Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/841d42cc4e2f9ca1cf59758fc15619b00a11e148 Modified Files -------------- src/backend/commands/operatorcmds.c | 57 +++++++++++++++++++++++++------- src/backend/tsearch/ts_selfuncs.c | 8 +++-- src/backend/utils/adt/network_selfuncs.c | 48 ++++++++++++++++++--------- 3 files changed, 83 insertions(+), 30 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Require superuser to install a non-built-in selectivity estimato @ 2026-02-09 15:15 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-09 15:15 UTC (permalink / raw) To: [email protected] Require superuser to install a non-built-in selectivity estimator. Selectivity estimators come in two flavors: those that make specific assumptions about the data types they are working with, and those that don't. Most of the built-in estimators are of the latter kind and are meant to be safely attachable to any operator. If the operator does not behave as the estimator expects, you might get a poor estimate, but it won't crash. However, estimators that do make datatype assumptions can malfunction if they are attached to the wrong operator, since then the data they get from pg_statistic may not be of the type they expect. This can rise to the level of a security problem, even permitting arbitrary code execution by a user who has the ability to create SQL objects. To close this hole, establish a rule that built-in estimators are required to protect themselves against being called on the wrong type of data. It does not seem practical however to expect estimators in extensions to reach a similar level of security, at least not in the near term. Therefore, also establish a rule that superuser privilege is required to attach a non-built-in estimator to an operator. We expect that this restriction will have little negative impact on extensions, since estimators generally have to be written in C and thus superuser privilege is required to create them in the first place. This commit changes the privilege checks in CREATE/ALTER OPERATOR to enforce the rule about superuser privilege, and fixes a couple of built-in estimators that were making datatype assumptions without sufficiently checking that they're valid. Reported-by: Daniel Firer as part of zeroday.cloud Author: Tom Lane <[email protected]> Reviewed-by: Noah Misch <[email protected]> Security: CVE-2026-2004 Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/66ddac6982c6dc0369dc7b2d251f4d210d704a57 Modified Files -------------- src/backend/commands/operatorcmds.c | 57 +++++++++++++++++++++++++------- src/backend/tsearch/ts_selfuncs.c | 8 +++-- src/backend/utils/adt/network_selfuncs.c | 48 ++++++++++++++++++--------- 3 files changed, 83 insertions(+), 30 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Require superuser to install a non-built-in selectivity estimato @ 2026-02-09 15:15 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-09 15:15 UTC (permalink / raw) To: [email protected] Require superuser to install a non-built-in selectivity estimator. Selectivity estimators come in two flavors: those that make specific assumptions about the data types they are working with, and those that don't. Most of the built-in estimators are of the latter kind and are meant to be safely attachable to any operator. If the operator does not behave as the estimator expects, you might get a poor estimate, but it won't crash. However, estimators that do make datatype assumptions can malfunction if they are attached to the wrong operator, since then the data they get from pg_statistic may not be of the type they expect. This can rise to the level of a security problem, even permitting arbitrary code execution by a user who has the ability to create SQL objects. To close this hole, establish a rule that built-in estimators are required to protect themselves against being called on the wrong type of data. It does not seem practical however to expect estimators in extensions to reach a similar level of security, at least not in the near term. Therefore, also establish a rule that superuser privilege is required to attach a non-built-in estimator to an operator. We expect that this restriction will have little negative impact on extensions, since estimators generally have to be written in C and thus superuser privilege is required to create them in the first place. This commit changes the privilege checks in CREATE/ALTER OPERATOR to enforce the rule about superuser privilege, and fixes a couple of built-in estimators that were making datatype assumptions without sufficiently checking that they're valid. Reported-by: Daniel Firer as part of zeroday.cloud Author: Tom Lane <[email protected]> Reviewed-by: Noah Misch <[email protected]> Security: CVE-2026-2004 Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ea3bf34986032ba2760538dacbc144b1f6e300fd Modified Files -------------- src/backend/commands/operatorcmds.c | 55 +++++++++++++++++++++++++------- src/backend/tsearch/ts_selfuncs.c | 8 +++-- src/backend/utils/adt/network_selfuncs.c | 48 +++++++++++++++++++--------- 3 files changed, 81 insertions(+), 30 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Require superuser to install a non-built-in selectivity estimato @ 2026-02-09 15:15 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2026-02-09 15:15 UTC (permalink / raw) To: [email protected] Require superuser to install a non-built-in selectivity estimator. Selectivity estimators come in two flavors: those that make specific assumptions about the data types they are working with, and those that don't. Most of the built-in estimators are of the latter kind and are meant to be safely attachable to any operator. If the operator does not behave as the estimator expects, you might get a poor estimate, but it won't crash. However, estimators that do make datatype assumptions can malfunction if they are attached to the wrong operator, since then the data they get from pg_statistic may not be of the type they expect. This can rise to the level of a security problem, even permitting arbitrary code execution by a user who has the ability to create SQL objects. To close this hole, establish a rule that built-in estimators are required to protect themselves against being called on the wrong type of data. It does not seem practical however to expect estimators in extensions to reach a similar level of security, at least not in the near term. Therefore, also establish a rule that superuser privilege is required to attach a non-built-in estimator to an operator. We expect that this restriction will have little negative impact on extensions, since estimators generally have to be written in C and thus superuser privilege is required to create them in the first place. This commit changes the privilege checks in CREATE/ALTER OPERATOR to enforce the rule about superuser privilege, and fixes a couple of built-in estimators that were making datatype assumptions without sufficiently checking that they're valid. Reported-by: Daniel Firer as part of zeroday.cloud Author: Tom Lane <[email protected]> Reviewed-by: Noah Misch <[email protected]> Security: CVE-2026-2004 Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b764b26f2e0a0a57057f301ca87e6a604f5e708b Modified Files -------------- src/backend/commands/operatorcmds.c | 55 +++++++++++++++++++++++++------- src/backend/tsearch/ts_selfuncs.c | 8 +++-- src/backend/utils/adt/network_selfuncs.c | 48 +++++++++++++++++++--------- 3 files changed, 81 insertions(+), 30 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-02-09 15:15 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-02-09 15:15 pgsql: Require superuser to install a non-built-in selectivity estimato Tom Lane <[email protected]> 2026-02-09 15:15 pgsql: Require superuser to install a non-built-in selectivity estimato Tom Lane <[email protected]> 2026-02-09 15:15 pgsql: Require superuser to install a non-built-in selectivity estimato Tom Lane <[email protected]> 2026-02-09 15:15 pgsql: Require superuser to install a non-built-in selectivity estimato Tom Lane <[email protected]> 2026-02-09 15:15 pgsql: Require superuser to install a non-built-in selectivity estimato Tom Lane <[email protected]> 2026-02-09 15:15 pgsql: Require superuser to install a non-built-in selectivity estimato Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox