pgsql: Fix race conditions with drop of reused pgstats entries
Fix race conditions with drop of reused pgstats entries This fixes a set of race conditions with cumulative statistics where a shared stats entry could be dropped while it should still be valid in the event when it is reused: an entry may refer to a different object but requires the same hash key. This can happen with various stats kinds, like: - Replication slots that compute internally an index number, for different slot names. - Stats kinds that use an OID in the object key, where a wraparound causes the same key to be used if an OID is used for the same object. - As of PostgreSQL 18, custom pgstats kinds could also be an issue, depending on their implementation. This issue is fixed by introducing a counter called "generation" in the shared entries via PgStatShared_HashEntry, initialized at 0 when an entry is created and incremented when the same entry is reused, to avoid concurrent issues on drop because of other backends still holding a reference to it. This "generation" is copied to the local copy that a backend holds when looking at an object, then cross-checked with the shared entry to make sure that the entry is not dropped even if its "refcount" justifies that if it has been reused. This problem could show up when a backend shuts down and needs to discard any entries it still holds, causing statistics to be removed when they should not, or even an assertion failure. Another report involved a failure in a standby after an OID wraparound, where the startup process would FATAL on a "can only drop stats once", stopping recovery abruptly. The buildfarm has been sporadically complaining about the problem, as well, but the window is hard to reach with the in-core tests. Note that the issue can be reproduced easily by adding a sleep before dshash_find() in pgstat_release_entry_ref() to enlarge the problematic window while repeating test_decoding's isolation test oldest_xmin a couple of times, for example, as pointed out by Alexander Lakhin. Reported-by: Alexander Lakhin, Peter Smith Author: Kyotaro Horiguchi, Michael Paquier Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/caa4ek1kxumvyaryz_vk5yq3ejgkycl6f45hj9znmnbs-g+p...@mail.gmail.com Discussion: https://postgr.es/m/17947-b9554521ad963...@postgresql.org Backpatch-through: 15 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1d6a03ea41469f78b33479ea1d2f603f3510b18b Modified Files -- src/backend/utils/activity/pgstat_shmem.c | 40 +++ src/include/utils/pgstat_internal.h | 19 +++ 2 files changed, 54 insertions(+), 5 deletions(-)
pgsql: Fix race conditions with drop of reused pgstats entries
Fix race conditions with drop of reused pgstats entries This fixes a set of race conditions with cumulative statistics where a shared stats entry could be dropped while it should still be valid in the event when it is reused: an entry may refer to a different object but requires the same hash key. This can happen with various stats kinds, like: - Replication slots that compute internally an index number, for different slot names. - Stats kinds that use an OID in the object key, where a wraparound causes the same key to be used if an OID is used for the same object. - As of PostgreSQL 18, custom pgstats kinds could also be an issue, depending on their implementation. This issue is fixed by introducing a counter called "generation" in the shared entries via PgStatShared_HashEntry, initialized at 0 when an entry is created and incremented when the same entry is reused, to avoid concurrent issues on drop because of other backends still holding a reference to it. This "generation" is copied to the local copy that a backend holds when looking at an object, then cross-checked with the shared entry to make sure that the entry is not dropped even if its "refcount" justifies that if it has been reused. This problem could show up when a backend shuts down and needs to discard any entries it still holds, causing statistics to be removed when they should not, or even an assertion failure. Another report involved a failure in a standby after an OID wraparound, where the startup process would FATAL on a "can only drop stats once", stopping recovery abruptly. The buildfarm has been sporadically complaining about the problem, as well, but the window is hard to reach with the in-core tests. Note that the issue can be reproduced easily by adding a sleep before dshash_find() in pgstat_release_entry_ref() to enlarge the problematic window while repeating test_decoding's isolation test oldest_xmin a couple of times, for example, as pointed out by Alexander Lakhin. Reported-by: Alexander Lakhin, Peter Smith Author: Kyotaro Horiguchi, Michael Paquier Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/caa4ek1kxumvyaryz_vk5yq3ejgkycl6f45hj9znmnbs-g+p...@mail.gmail.com Discussion: https://postgr.es/m/17947-b9554521ad963...@postgresql.org Backpatch-through: 15 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/154c5b42a3d80424f7b7beef33a69600245c147d Modified Files -- src/backend/utils/activity/pgstat_shmem.c | 40 +++ src/include/utils/pgstat_internal.h | 19 +++ 2 files changed, 54 insertions(+), 5 deletions(-)
pgsql: Fix race conditions with drop of reused pgstats entries
Fix race conditions with drop of reused pgstats entries This fixes a set of race conditions with cumulative statistics where a shared stats entry could be dropped while it should still be valid in the event when it is reused: an entry may refer to a different object but requires the same hash key. This can happen with various stats kinds, like: - Replication slots that compute internally an index number, for different slot names. - Stats kinds that use an OID in the object key, where a wraparound causes the same key to be used if an OID is used for the same object. - As of PostgreSQL 18, custom pgstats kinds could also be an issue, depending on their implementation. This issue is fixed by introducing a counter called "generation" in the shared entries via PgStatShared_HashEntry, initialized at 0 when an entry is created and incremented when the same entry is reused, to avoid concurrent issues on drop because of other backends still holding a reference to it. This "generation" is copied to the local copy that a backend holds when looking at an object, then cross-checked with the shared entry to make sure that the entry is not dropped even if its "refcount" justifies that if it has been reused. This problem could show up when a backend shuts down and needs to discard any entries it still holds, causing statistics to be removed when they should not, or even an assertion failure. Another report involved a failure in a standby after an OID wraparound, where the startup process would FATAL on a "can only drop stats once", stopping recovery abruptly. The buildfarm has been sporadically complaining about the problem, as well, but the window is hard to reach with the in-core tests. Note that the issue can be reproduced easily by adding a sleep before dshash_find() in pgstat_release_entry_ref() to enlarge the problematic window while repeating test_decoding's isolation test oldest_xmin a couple of times, for example, as pointed out by Alexander Lakhin. Reported-by: Alexander Lakhin, Peter Smith Author: Kyotaro Horiguchi, Michael Paquier Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/caa4ek1kxumvyaryz_vk5yq3ejgkycl6f45hj9znmnbs-g+p...@mail.gmail.com Discussion: https://postgr.es/m/17947-b9554521ad963...@postgresql.org Backpatch-through: 15 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/818119afccd342823e5b638be51f64ba36221318 Modified Files -- src/backend/utils/activity/pgstat_shmem.c | 40 +++ src/include/utils/pgstat_internal.h | 19 +++ 2 files changed, 54 insertions(+), 5 deletions(-)
pgsql: Fix race conditions with drop of reused pgstats entries
Fix race conditions with drop of reused pgstats entries This fixes a set of race conditions with cumulative statistics where a shared stats entry could be dropped while it should still be valid in the event when it is reused: an entry may refer to a different object but requires the same hash key. This can happen with various stats kinds, like: - Replication slots that compute internally an index number, for different slot names. - Stats kinds that use an OID in the object key, where a wraparound causes the same key to be used if an OID is used for the same object. - As of PostgreSQL 18, custom pgstats kinds could also be an issue, depending on their implementation. This issue is fixed by introducing a counter called "generation" in the shared entries via PgStatShared_HashEntry, initialized at 0 when an entry is created and incremented when the same entry is reused, to avoid concurrent issues on drop because of other backends still holding a reference to it. This "generation" is copied to the local copy that a backend holds when looking at an object, then cross-checked with the shared entry to make sure that the entry is not dropped even if its "refcount" justifies that if it has been reused. This problem could show up when a backend shuts down and needs to discard any entries it still holds, causing statistics to be removed when they should not, or even an assertion failure. Another report involved a failure in a standby after an OID wraparound, where the startup process would FATAL on a "can only drop stats once", stopping recovery abruptly. The buildfarm has been sporadically complaining about the problem, as well, but the window is hard to reach with the in-core tests. Note that the issue can be reproduced easily by adding a sleep before dshash_find() in pgstat_release_entry_ref() to enlarge the problematic window while repeating test_decoding's isolation test oldest_xmin a couple of times, for example, as pointed out by Alexander Lakhin. Reported-by: Alexander Lakhin, Peter Smith Author: Kyotaro Horiguchi, Michael Paquier Reviewed-by: Bertrand Drouvot Discussion: https://postgr.es/m/caa4ek1kxumvyaryz_vk5yq3ejgkycl6f45hj9znmnbs-g+p...@mail.gmail.com Discussion: https://postgr.es/m/17947-b9554521ad963...@postgresql.org Backpatch-through: 15 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/afa20845dd1348f602989155864fb2ff57f481d8 Modified Files -- src/backend/utils/activity/pgstat_shmem.c | 40 +++ src/include/utils/pgstat_internal.h | 19 +++ 2 files changed, 54 insertions(+), 5 deletions(-)
pgsql: Remove a useless cast to (void *) in hash_search() call
Remove a useless cast to (void *) in hash_search() call This pattern was previously cleaned up in 54a177a948b, but a new instance snuck in around the same time in 31966b151e6. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a274bbb1b3655ae122bba792c8fb9ae8f0ac5b21 Modified Files -- src/backend/storage/buffer/localbuf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Replace postmaster.c's own backend type codes with BackendType
Replace postmaster.c's own backend type codes with BackendType Introduce a separate BackendType for dead-end children, so that we don't need a separate dead_end flag. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/a102f15f-eac4-4ff2-af02-f9ff209ec...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/18d67a8d7d30884655d65910b82781d9360819a6 Modified Files -- src/backend/postmaster/launch_backend.c | 1 + src/backend/postmaster/postmaster.c | 235 ++-- src/backend/utils/activity/pgstat_io.c | 3 + src/backend/utils/init/miscinit.c | 43 +++--- src/include/miscadmin.h | 1 + src/tools/pgindent/typedefs.list| 1 + 6 files changed, 168 insertions(+), 116 deletions(-)
pgsql: Block environment variable mutations from trusted PL/Perl.
Block environment variable mutations from trusted PL/Perl. Many process environment variables (e.g. PATH), bypass the containment expected of a trusted PL. Hence, trusted PLs must not offer features that achieve setenv(). Otherwise, an attacker having USAGE privilege on the language often can achieve arbitrary code execution, even if the attacker lacks a database server operating system user. To fix PL/Perl, replace trusted PL/Perl %ENV with a tied hash that just replaces each modification attempt with a warning. Sites that reach these warnings should evaluate the application-specific implications of proceeding without the environment modification: Can the application reasonably proceed without the modification? If no, switch to plperlu or another approach. If yes, the application should change the code to stop attempting environment modifications. If that's too difficult, add "untie %main::ENV" in any code executed before the warning. For example, one might add it to the start of the affected function or even to the plperl.on_plperl_init setting. In passing, link to Perl's guidance about the Perl features behind the security posture of PL/Perl. Back-patch to v12 (all supported versions). Andrew Dunstan and Noah Misch Security: CVE-2024-10979 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d15ec27c977100037ae513ab7fe1a214bfc2507b Modified Files -- doc/src/sgml/plperl.sgml | 13 + src/pl/plperl/GNUmakefile | 4 +-- src/pl/plperl/input/plperl_env.source | 52 ++ src/pl/plperl/output/plperl_env.source | 49 src/pl/plperl/plc_trusted.pl | 24 src/test/regress/regress.c | 24 6 files changed, 164 insertions(+), 2 deletions(-)
pgsql: Add needed .gitignore files in back branches.
Add needed .gitignore files in back branches. v14 and earlier use generated test files, which require being .gitignore'd to avoid git complaints when testing in-tree. Security: CVE-2024-10979 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b1e58defb6a43fe35511eaa80858293b07c8b512 Modified Files -- src/pl/plperl/expected/.gitignore | 1 + src/pl/plperl/sql/.gitignore | 1 + 2 files changed, 2 insertions(+)
pgsql: Fix improper interactions between session_authorization and role
Fix improper interactions between session_authorization and role.
The SQL spec mandates that SET SESSION AUTHORIZATION implies
SET ROLE NONE. We tried to implement that within the lowest-level
functions that manipulate these settings, but that was a bad idea.
In particular, guc.c assumes that it doesn't matter in what order
it applies GUC variable updates, but that was not the case for these
two variables. This problem, compounded by some hackish attempts to
work around it, led to some security-grade issues:
* Rolling back a transaction that had done SET SESSION AUTHORIZATION
would revert to SET ROLE NONE, even if that had not been the previous
state, so that the effective user ID might now be different from what
it had been.
* The same for SET SESSION AUTHORIZATION in a function SET clause.
* If a parallel worker inspected current_setting('role'), it saw
"none" even when it should see something else.
Also, although the parallel worker startup code intended to cope
with the current role's pg_authid row having disappeared, its
implementation of that was incomplete so it would still fail.
Fix by fully separating the miscinit.c functions that assign
session_authorization from those that assign role. To implement the
spec's requirement, teach set_config_option itself to perform "SET
ROLE NONE" when it sets session_authorization. (This is undoubtedly
ugly, but the alternatives seem worse. In particular, there's no way
to do it within assign_session_authorization without incompatible
changes in the API for GUC assign hooks.) Also, improve
ParallelWorkerMain to directly set all the relevant user-ID variables
instead of relying on some of them to get set indirectly. That
allows us to survive not finding the pg_authid row during worker
startup.
In v16 and earlier, this includes back-patching 9987a7bf3 which
fixed a violation of GUC coding rules: SetSessionAuthorization
is not an appropriate place to be throwing errors from.
Security: CVE-2024-10978
Branch
--
REL_17_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/cd82afdda5e9d3269706a142e9093ba83f484185
Modified Files
--
src/backend/access/transam/parallel.c| 33 +---
src/backend/commands/variable.c | 121 +-
src/backend/utils/init/miscinit.c| 124 ---
src/backend/utils/misc/guc.c | 43 +--
src/include/miscadmin.h | 2 +
src/test/regress/expected/privileges.out | 67 +
src/test/regress/sql/privileges.sql | 33
7 files changed, 310 insertions(+), 113 deletions(-)
pgsql: Ensure cached plans are correctly marked as dependent on role.
Ensure cached plans are correctly marked as dependent on role. If a CTE, subquery, sublink, security invoker view, or coercion projection references a table with row-level security policies, we neglected to mark the plan as potentially dependent on which role is executing it. This could lead to later executions in the same session returning or hiding rows that should have been hidden or returned instead. Reported-by: Wolfgang Walther Reviewed-by: Noah Misch Security: CVE-2024-10976 Backpatch-through: 12 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/edcda9bb4c4500b75bb4a16c7c59834398ca2906 Modified Files -- src/backend/executor/functions.c | 6 ++ src/backend/rewrite/rewriteHandler.c | 67 ++-- src/test/regress/expected/rowsecurity.out | 100 ++ src/test/regress/sql/rowsecurity.sql | 58 + src/tools/pgindent/typedefs.list | 1 + 5 files changed, 226 insertions(+), 6 deletions(-)
pgsql: Fix improper interactions between session_authorization and role
Fix improper interactions between session_authorization and role.
The SQL spec mandates that SET SESSION AUTHORIZATION implies
SET ROLE NONE. We tried to implement that within the lowest-level
functions that manipulate these settings, but that was a bad idea.
In particular, guc.c assumes that it doesn't matter in what order
it applies GUC variable updates, but that was not the case for these
two variables. This problem, compounded by some hackish attempts to
work around it, led to some security-grade issues:
* Rolling back a transaction that had done SET SESSION AUTHORIZATION
would revert to SET ROLE NONE, even if that had not been the previous
state, so that the effective user ID might now be different from what
it had been.
* The same for SET SESSION AUTHORIZATION in a function SET clause.
* If a parallel worker inspected current_setting('role'), it saw
"none" even when it should see something else.
Also, although the parallel worker startup code intended to cope
with the current role's pg_authid row having disappeared, its
implementation of that was incomplete so it would still fail.
Fix by fully separating the miscinit.c functions that assign
session_authorization from those that assign role. To implement the
spec's requirement, teach set_config_option itself to perform "SET
ROLE NONE" when it sets session_authorization. (This is undoubtedly
ugly, but the alternatives seem worse. In particular, there's no way
to do it within assign_session_authorization without incompatible
changes in the API for GUC assign hooks.) Also, improve
ParallelWorkerMain to directly set all the relevant user-ID variables
instead of relying on some of them to get set indirectly. That
allows us to survive not finding the pg_authid row during worker
startup.
In v16 and earlier, this includes back-patching 9987a7bf3 which
fixed a violation of GUC coding rules: SetSessionAuthorization
is not an appropriate place to be throwing errors from.
Security: CVE-2024-10978
Branch
--
REL_16_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/ae340d0318521ae7234ed3b7221a1f65f39a52c0
Modified Files
--
src/backend/access/transam/parallel.c| 36 +--
src/backend/commands/variable.c | 101 ++--
src/backend/utils/init/miscinit.c| 157 ++-
src/backend/utils/misc/guc.c | 43 +++--
src/include/miscadmin.h | 3 +
src/test/regress/expected/privileges.out | 67 +
src/test/regress/sql/privileges.sql | 33 +++
7 files changed, 330 insertions(+), 110 deletions(-)
pgsql: Fix improper interactions between session_authorization and role
Fix improper interactions between session_authorization and role.
The SQL spec mandates that SET SESSION AUTHORIZATION implies
SET ROLE NONE. We tried to implement that within the lowest-level
functions that manipulate these settings, but that was a bad idea.
In particular, guc.c assumes that it doesn't matter in what order
it applies GUC variable updates, but that was not the case for these
two variables. This problem, compounded by some hackish attempts to
work around it, led to some security-grade issues:
* Rolling back a transaction that had done SET SESSION AUTHORIZATION
would revert to SET ROLE NONE, even if that had not been the previous
state, so that the effective user ID might now be different from what
it had been.
* The same for SET SESSION AUTHORIZATION in a function SET clause.
* If a parallel worker inspected current_setting('role'), it saw
"none" even when it should see something else.
Also, although the parallel worker startup code intended to cope
with the current role's pg_authid row having disappeared, its
implementation of that was incomplete so it would still fail.
Fix by fully separating the miscinit.c functions that assign
session_authorization from those that assign role. To implement the
spec's requirement, teach set_config_option itself to perform "SET
ROLE NONE" when it sets session_authorization. (This is undoubtedly
ugly, but the alternatives seem worse. In particular, there's no way
to do it within assign_session_authorization without incompatible
changes in the API for GUC assign hooks.) Also, improve
ParallelWorkerMain to directly set all the relevant user-ID variables
instead of relying on some of them to get set indirectly. That
allows us to survive not finding the pg_authid row during worker
startup.
In v16 and earlier, this includes back-patching 9987a7bf3 which
fixed a violation of GUC coding rules: SetSessionAuthorization
is not an appropriate place to be throwing errors from.
Security: CVE-2024-10978
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/76123ded6e9b3624e380ac326645bd026aacd2f5
Modified Files
--
src/backend/access/transam/parallel.c| 36 +--
src/backend/commands/variable.c | 101 ++--
src/backend/utils/init/miscinit.c| 157 ++-
src/backend/utils/misc/guc.c | 40 ++--
src/include/miscadmin.h | 3 +
src/test/regress/expected/privileges.out | 73 ++
src/test/regress/sql/privileges.sql | 40
7 files changed, 341 insertions(+), 109 deletions(-)
pgsql: Avoid bizarre meson behavior with backslashes in command argumen
Avoid bizarre meson behavior with backslashes in command arguments. meson makes the backslashes in text2macro.pl's --strip argument into forward slashes, effectively disabling comment stripping. That hasn't caused us issues before, but it breaks the test case for b7e3a52a8. We don't really need the pattern to be adjustable, so just hard-wire it into the script instead. Context: https://github.com/mesonbuild/meson/issues/1564 Security: CVE-2024-10979 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a34c33fd2278157de140608523598567bfb7a32f Modified Files -- src/pl/plperl/GNUmakefile | 2 +- src/pl/plperl/meson.build | 2 +- src/pl/plperl/text2macro.pl | 8 +--- 3 files changed, 7 insertions(+), 5 deletions(-)
pgsql: Avoid bizarre meson behavior with backslashes in command argumen
Avoid bizarre meson behavior with backslashes in command arguments. meson makes the backslashes in text2macro.pl's --strip argument into forward slashes, effectively disabling comment stripping. That hasn't caused us issues before, but it breaks the test case for b7e3a52a8. We don't really need the pattern to be adjustable, so just hard-wire it into the script instead. Context: https://github.com/mesonbuild/meson/issues/1564 Security: CVE-2024-10979 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/88269df4da032bb1536d4291a13f3af4e1e599ba Modified Files -- src/pl/plperl/GNUmakefile | 2 +- src/pl/plperl/meson.build | 2 +- src/pl/plperl/text2macro.pl | 8 +--- 3 files changed, 7 insertions(+), 5 deletions(-)
pgsql: Fix improper interactions between session_authorization and role
Fix improper interactions between session_authorization and role.
The SQL spec mandates that SET SESSION AUTHORIZATION implies
SET ROLE NONE. We tried to implement that within the lowest-level
functions that manipulate these settings, but that was a bad idea.
In particular, guc.c assumes that it doesn't matter in what order
it applies GUC variable updates, but that was not the case for these
two variables. This problem, compounded by some hackish attempts to
work around it, led to some security-grade issues:
* Rolling back a transaction that had done SET SESSION AUTHORIZATION
would revert to SET ROLE NONE, even if that had not been the previous
state, so that the effective user ID might now be different from what
it had been.
* The same for SET SESSION AUTHORIZATION in a function SET clause.
* If a parallel worker inspected current_setting('role'), it saw
"none" even when it should see something else.
Also, although the parallel worker startup code intended to cope
with the current role's pg_authid row having disappeared, its
implementation of that was incomplete so it would still fail.
Fix by fully separating the miscinit.c functions that assign
session_authorization from those that assign role. To implement the
spec's requirement, teach set_config_option itself to perform "SET
ROLE NONE" when it sets session_authorization. (This is undoubtedly
ugly, but the alternatives seem worse. In particular, there's no way
to do it within assign_session_authorization without incompatible
changes in the API for GUC assign hooks.) Also, improve
ParallelWorkerMain to directly set all the relevant user-ID variables
instead of relying on some of them to get set indirectly. That
allows us to survive not finding the pg_authid row during worker
startup.
In v16 and earlier, this includes back-patching 9987a7bf3 which
fixed a violation of GUC coding rules: SetSessionAuthorization
is not an appropriate place to be throwing errors from.
Security: CVE-2024-10978
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/4c9d96f74ba4e7d01c086ca54f217e242dd65fae
Modified Files
--
src/backend/access/transam/parallel.c| 36 +--
src/backend/commands/variable.c | 101 ++--
src/backend/utils/init/miscinit.c| 157 ++-
src/backend/utils/misc/guc.c | 40 ++--
src/include/miscadmin.h | 3 +
src/test/regress/expected/privileges.out | 73 ++
src/test/regress/sql/privileges.sql | 40
7 files changed, 341 insertions(+), 109 deletions(-)
pgsql: Fix improper interactions between session_authorization and role
Fix improper interactions between session_authorization and role.
The SQL spec mandates that SET SESSION AUTHORIZATION implies
SET ROLE NONE. We tried to implement that within the lowest-level
functions that manipulate these settings, but that was a bad idea.
In particular, guc.c assumes that it doesn't matter in what order
it applies GUC variable updates, but that was not the case for these
two variables. This problem, compounded by some hackish attempts to
work around it, led to some security-grade issues:
* Rolling back a transaction that had done SET SESSION AUTHORIZATION
would revert to SET ROLE NONE, even if that had not been the previous
state, so that the effective user ID might now be different from what
it had been.
* The same for SET SESSION AUTHORIZATION in a function SET clause.
* If a parallel worker inspected current_setting('role'), it saw
"none" even when it should see something else.
Also, although the parallel worker startup code intended to cope
with the current role's pg_authid row having disappeared, its
implementation of that was incomplete so it would still fail.
Fix by fully separating the miscinit.c functions that assign
session_authorization from those that assign role. To implement the
spec's requirement, teach set_config_option itself to perform "SET
ROLE NONE" when it sets session_authorization. (This is undoubtedly
ugly, but the alternatives seem worse. In particular, there's no way
to do it within assign_session_authorization without incompatible
changes in the API for GUC assign hooks.) Also, improve
ParallelWorkerMain to directly set all the relevant user-ID variables
instead of relying on some of them to get set indirectly. That
allows us to survive not finding the pg_authid row during worker
startup.
In v16 and earlier, this includes back-patching 9987a7bf3 which
fixed a violation of GUC coding rules: SetSessionAuthorization
is not an appropriate place to be throwing errors from.
Security: CVE-2024-10978
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/5a2fed911a85ed6d8a015a6bafe3a0d9a69334ae
Modified Files
--
src/backend/access/transam/parallel.c| 37 ++---
src/backend/commands/variable.c | 121 +-
src/backend/utils/init/miscinit.c| 124 ---
src/backend/utils/misc/guc.c | 43 +--
src/include/miscadmin.h | 2 +
src/test/regress/expected/privileges.out | 67 +
src/test/regress/sql/privileges.sql | 33
7 files changed, 313 insertions(+), 114 deletions(-)
pgsql: Avoid bizarre meson behavior with backslashes in command argumen
Avoid bizarre meson behavior with backslashes in command arguments. meson makes the backslashes in text2macro.pl's --strip argument into forward slashes, effectively disabling comment stripping. That hasn't caused us issues before, but it breaks the test case for b7e3a52a8. We don't really need the pattern to be adjustable, so just hard-wire it into the script instead. Context: https://github.com/mesonbuild/meson/issues/1564 Security: CVE-2024-10979 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4cd4f3b97492c1b38115d0563a2e55b136eb542a Modified Files -- src/pl/plperl/GNUmakefile | 2 +- src/pl/plperl/meson.build | 2 +- src/pl/plperl/text2macro.pl | 8 +--- 3 files changed, 7 insertions(+), 5 deletions(-)
pgsql: Fix cross-version upgrade tests.
Fix cross-version upgrade tests. TestUpgradeXversion knows how to make the main regression database's references to pg_regress.so be version-independent. But it doesn't do that for plperl's database, so that the C function added by commit b7e3a52a8 is causing cross-version upgrade test failures. Path of least resistance is to just drop the function at the end of the new test. In <= v14, also take the opportunity to clean up the generated test files. Security: CVE-2024-10979 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/64df8870097aa286363a5d81462802783abbfa61 Modified Files -- src/pl/plperl/expected/plperl_env.out | 2 ++ src/pl/plperl/sql/plperl_env.sql | 3 +++ 2 files changed, 5 insertions(+)
pgsql: Avoid bizarre meson behavior with backslashes in command argumen
Avoid bizarre meson behavior with backslashes in command arguments. Ooops, missed that v16 has another text2macro call in the MSVC scripts. Security: CVE-2024-10979 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/168579e23bdbeda1a140440c0272b335d53ad061 Modified Files -- src/tools/msvc/Mkvcbuild.pm | 1 - 1 file changed, 1 deletion(-)
pgsql: Fix cross-version upgrade tests.
Fix cross-version upgrade tests. TestUpgradeXversion knows how to make the main regression database's references to pg_regress.so be version-independent. But it doesn't do that for plperl's database, so that the C function added by commit b7e3a52a8 is causing cross-version upgrade test failures. Path of least resistance is to just drop the function at the end of the new test. In <= v14, also take the opportunity to clean up the generated test files. Security: CVE-2024-10979 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0bd9560d964abc09e446e4c5e264bb7a0886e5ea Modified Files -- src/pl/plperl/GNUmakefile | 1 + src/pl/plperl/input/plperl_env.source | 3 +++ src/pl/plperl/output/plperl_env.source | 2 ++ 3 files changed, 6 insertions(+)
pgsql: Block environment variable mutations from trusted PL/Perl.
Block environment variable mutations from trusted PL/Perl. Many process environment variables (e.g. PATH), bypass the containment expected of a trusted PL. Hence, trusted PLs must not offer features that achieve setenv(). Otherwise, an attacker having USAGE privilege on the language often can achieve arbitrary code execution, even if the attacker lacks a database server operating system user. To fix PL/Perl, replace trusted PL/Perl %ENV with a tied hash that just replaces each modification attempt with a warning. Sites that reach these warnings should evaluate the application-specific implications of proceeding without the environment modification: Can the application reasonably proceed without the modification? If no, switch to plperlu or another approach. If yes, the application should change the code to stop attempting environment modifications. If that's too difficult, add "untie %main::ENV" in any code executed before the warning. For example, one might add it to the start of the affected function or even to the plperl.on_plperl_init setting. In passing, link to Perl's guidance about the Perl features behind the security posture of PL/Perl. Back-patch to v12 (all supported versions). Andrew Dunstan and Noah Misch Security: CVE-2024-10979 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8fe3e697a1a83a722b107c7cb9c31084e1f4d077 Modified Files -- doc/src/sgml/plperl.sgml | 13 src/pl/plperl/GNUmakefile | 4 +-- src/pl/plperl/expected/plperl_env.out | 53 src/pl/plperl/meson.build | 2 ++ src/pl/plperl/plc_trusted.pl | 24 +++ src/pl/plperl/sql/plperl_env.sql | 58 +++ src/test/regress/regress.c| 23 ++ 7 files changed, 175 insertions(+), 2 deletions(-)
pgsql: Block environment variable mutations from trusted PL/Perl.
Block environment variable mutations from trusted PL/Perl. Many process environment variables (e.g. PATH), bypass the containment expected of a trusted PL. Hence, trusted PLs must not offer features that achieve setenv(). Otherwise, an attacker having USAGE privilege on the language often can achieve arbitrary code execution, even if the attacker lacks a database server operating system user. To fix PL/Perl, replace trusted PL/Perl %ENV with a tied hash that just replaces each modification attempt with a warning. Sites that reach these warnings should evaluate the application-specific implications of proceeding without the environment modification: Can the application reasonably proceed without the modification? If no, switch to plperlu or another approach. If yes, the application should change the code to stop attempting environment modifications. If that's too difficult, add "untie %main::ENV" in any code executed before the warning. For example, one might add it to the start of the affected function or even to the plperl.on_plperl_init setting. In passing, link to Perl's guidance about the Perl features behind the security posture of PL/Perl. Back-patch to v12 (all supported versions). Andrew Dunstan and Noah Misch Security: CVE-2024-10979 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e530835c6cc5b2dbf330ebe6b0a7fb9f19f5a54c Modified Files -- doc/src/sgml/plperl.sgml | 13 src/pl/plperl/GNUmakefile | 4 +-- src/pl/plperl/expected/plperl_env.out | 53 src/pl/plperl/plc_trusted.pl | 24 +++ src/pl/plperl/sql/plperl_env.sql | 58 +++ src/test/regress/regress.c| 23 ++ 6 files changed, 173 insertions(+), 2 deletions(-)
pgsql: Ensure cached plans are correctly marked as dependent on role.
Ensure cached plans are correctly marked as dependent on role. If a CTE, subquery, sublink, security invoker view, or coercion projection references a table with row-level security policies, we neglected to mark the plan as potentially dependent on which role is executing it. This could lead to later executions in the same session returning or hiding rows that should have been hidden or returned instead. Reported-by: Wolfgang Walther Reviewed-by: Noah Misch Security: CVE-2024-10976 Backpatch-through: 12 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4e51030af9e0a12d7fa06b73acd0c85024f81062 Modified Files -- src/backend/executor/functions.c | 6 +++ src/backend/rewrite/rewriteHandler.c | 67 +++--- src/test/regress/expected/rowsecurity.out | 78 +++ src/test/regress/sql/rowsecurity.sql | 44 + src/tools/pgindent/typedefs.list | 1 + 5 files changed, 190 insertions(+), 6 deletions(-)
pgsql: Add needed .gitignore files in back branches.
Add needed .gitignore files in back branches. v14 and earlier use generated test files, which require being .gitignore'd to avoid git complaints when testing in-tree. Security: CVE-2024-10979 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6bccd7b037d09b91ce272c68f43705e2fecd4cca Modified Files -- src/pl/plperl/expected/.gitignore | 1 + src/pl/plperl/sql/.gitignore | 1 + 2 files changed, 2 insertions(+)
pgsql: Fix cross-version upgrade tests.
Fix cross-version upgrade tests. TestUpgradeXversion knows how to make the main regression database's references to pg_regress.so be version-independent. But it doesn't do that for plperl's database, so that the C function added by commit b7e3a52a8 is causing cross-version upgrade test failures. Path of least resistance is to just drop the function at the end of the new test. In <= v14, also take the opportunity to clean up the generated test files. Security: CVE-2024-10979 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c4252c9ef0afea48a59402901c16fc970d838721 Modified Files -- src/pl/plperl/expected/plperl_env.out | 2 ++ src/pl/plperl/sql/plperl_env.sql | 3 +++ 2 files changed, 5 insertions(+)
pgsql: Fix improper interactions between session_authorization and role
Fix improper interactions between session_authorization and role.
The SQL spec mandates that SET SESSION AUTHORIZATION implies
SET ROLE NONE. We tried to implement that within the lowest-level
functions that manipulate these settings, but that was a bad idea.
In particular, guc.c assumes that it doesn't matter in what order
it applies GUC variable updates, but that was not the case for these
two variables. This problem, compounded by some hackish attempts to
work around it, led to some security-grade issues:
* Rolling back a transaction that had done SET SESSION AUTHORIZATION
would revert to SET ROLE NONE, even if that had not been the previous
state, so that the effective user ID might now be different from what
it had been.
* The same for SET SESSION AUTHORIZATION in a function SET clause.
* If a parallel worker inspected current_setting('role'), it saw
"none" even when it should see something else.
Also, although the parallel worker startup code intended to cope
with the current role's pg_authid row having disappeared, its
implementation of that was incomplete so it would still fail.
Fix by fully separating the miscinit.c functions that assign
session_authorization from those that assign role. To implement the
spec's requirement, teach set_config_option itself to perform "SET
ROLE NONE" when it sets session_authorization. (This is undoubtedly
ugly, but the alternatives seem worse. In particular, there's no way
to do it within assign_session_authorization without incompatible
changes in the API for GUC assign hooks.) Also, improve
ParallelWorkerMain to directly set all the relevant user-ID variables
instead of relying on some of them to get set indirectly. That
allows us to survive not finding the pg_authid row during worker
startup.
In v16 and earlier, this includes back-patching 9987a7bf3 which
fixed a violation of GUC coding rules: SetSessionAuthorization
is not an appropriate place to be throwing errors from.
Security: CVE-2024-10978
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/2a68808e241bf667ff72c31ea9d0c4eb0b893982
Modified Files
--
src/backend/access/transam/parallel.c| 36 +--
src/backend/commands/variable.c | 101 ++--
src/backend/utils/init/miscinit.c| 157 ++-
src/backend/utils/misc/guc.c | 41 ++--
src/include/miscadmin.h | 3 +
src/test/regress/expected/privileges.out | 73 ++
src/test/regress/sql/privileges.sql | 39
7 files changed, 340 insertions(+), 110 deletions(-)
pgsql: Fix cross-version upgrade tests.
Fix cross-version upgrade tests. TestUpgradeXversion knows how to make the main regression database's references to pg_regress.so be version-independent. But it doesn't do that for plperl's database, so that the C function added by commit b7e3a52a8 is causing cross-version upgrade test failures. Path of least resistance is to just drop the function at the end of the new test. In <= v14, also take the opportunity to clean up the generated test files. Security: CVE-2024-10979 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8d19f3fea003b1f744516b84cbdb0097ae7b2912 Modified Files -- src/pl/plperl/expected/plperl_env.out | 2 ++ src/pl/plperl/sql/plperl_env.sql | 3 +++ 2 files changed, 5 insertions(+)
pgsql: Fix cross-version upgrade tests.
Fix cross-version upgrade tests. TestUpgradeXversion knows how to make the main regression database's references to pg_regress.so be version-independent. But it doesn't do that for plperl's database, so that the C function added by commit b7e3a52a8 is causing cross-version upgrade test failures. Path of least resistance is to just drop the function at the end of the new test. In <= v14, also take the opportunity to clean up the generated test files. Security: CVE-2024-10979 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/256e34653aadd3582b98411d7d26f4fbb865e0ec Modified Files -- src/pl/plperl/GNUmakefile | 1 + src/pl/plperl/input/plperl_env.source | 3 +++ src/pl/plperl/output/plperl_env.source | 2 ++ 3 files changed, 6 insertions(+)
pgsql: Fix cross-version upgrade tests.
Fix cross-version upgrade tests. TestUpgradeXversion knows how to make the main regression database's references to pg_regress.so be version-independent. But it doesn't do that for plperl's database, so that the C function added by commit b7e3a52a8 is causing cross-version upgrade test failures. Path of least resistance is to just drop the function at the end of the new test. In <= v14, also take the opportunity to clean up the generated test files. Security: CVE-2024-10979 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c834b375a6dc36ff92f9f738ef1d7af09d91165f Modified Files -- src/pl/plperl/expected/plperl_env.out | 2 ++ src/pl/plperl/sql/plperl_env.sql | 3 +++ 2 files changed, 5 insertions(+)
pgsql: Fix cross-version upgrade tests.
Fix cross-version upgrade tests. TestUpgradeXversion knows how to make the main regression database's references to pg_regress.so be version-independent. But it doesn't do that for plperl's database, so that the C function added by commit b7e3a52a8 is causing cross-version upgrade test failures. Path of least resistance is to just drop the function at the end of the new test. In <= v14, also take the opportunity to clean up the generated test files. Security: CVE-2024-10979 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9fc1c3a02ddc4cf2a34550c0f985288cea7094bd Modified Files -- src/pl/plperl/GNUmakefile | 1 + src/pl/plperl/input/plperl_env.source | 3 +++ src/pl/plperl/output/plperl_env.source | 2 ++ 3 files changed, 6 insertions(+)
pgsql: Parallel workers use AuthenticatedUserId for connection privileg
Parallel workers use AuthenticatedUserId for connection privilege checks. Commit 5a2fed911 had an unexpected side-effect: the parallel worker launched for the new test case would fail if it couldn't use a superuser-reserved connection slot. The reason that test failed while all our pre-existing ones worked is that the connection privilege tests in InitPostgres had been based on the superuserness of the leader's AuthenticatedUserId, but after the rearrangements of 5a2fed911 we were testing the superuserness of CurrentUserId, which the new test case deliberately made to be a non-superuser. This all seems very accidental and probably not the behavior we really want, but a security patch is no time to be redesigning things. Pending some discussion about desirable semantics, hack it so that InitPostgres continues to pay attention to the superuserness of AuthenticatedUserId when starting a parallel worker. Nathan Bossart and Tom Lane, per buildfarm member sawshark. Security: CVE-2024-10978 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/109a323807d752f66699a9ce0762244f536e784f Modified Files -- src/backend/utils/init/postinit.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-)
pgsql: Add needed .gitignore files in back branches.
Add needed .gitignore files in back branches. v14 and earlier use generated test files, which require being .gitignore'd to avoid git complaints when testing in-tree. Security: CVE-2024-10979 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f89bd92c963c3be30a1cf26960aa86aaad117235 Modified Files -- src/pl/plperl/expected/.gitignore | 1 + src/pl/plperl/sql/.gitignore | 1 + 2 files changed, 2 insertions(+)
pgsql: Ensure cached plans are correctly marked as dependent on role.
Ensure cached plans are correctly marked as dependent on role. If a CTE, subquery, sublink, security invoker view, or coercion projection references a table with row-level security policies, we neglected to mark the plan as potentially dependent on which role is executing it. This could lead to later executions in the same session returning or hiding rows that should have been hidden or returned instead. Reported-by: Wolfgang Walther Reviewed-by: Noah Misch Security: CVE-2024-10976 Backpatch-through: 12 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/562289460e118fcad44ec916dcdab21e4763c38c Modified Files -- src/backend/executor/functions.c | 6 ++ src/backend/rewrite/rewriteHandler.c | 67 ++-- src/test/regress/expected/rowsecurity.out | 100 ++ src/test/regress/sql/rowsecurity.sql | 58 + src/tools/pgindent/typedefs.list | 1 + 5 files changed, 226 insertions(+), 6 deletions(-)
pgsql: Ensure cached plans are correctly marked as dependent on role.
Ensure cached plans are correctly marked as dependent on role. If a CTE, subquery, sublink, security invoker view, or coercion projection references a table with row-level security policies, we neglected to mark the plan as potentially dependent on which role is executing it. This could lead to later executions in the same session returning or hiding rows that should have been hidden or returned instead. Reported-by: Wolfgang Walther Reviewed-by: Noah Misch Security: CVE-2024-10976 Backpatch-through: 12 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/448525e8a44080b6048e24f6942284b7eeae1a5c Modified Files -- src/backend/rewrite/rewriteHandler.c | 67 --- src/test/regress/expected/rowsecurity.out | 58 ++ src/test/regress/sql/rowsecurity.sql | 33 +++ src/tools/pgindent/typedefs.list | 1 + 4 files changed, 153 insertions(+), 6 deletions(-)
pgsql: Kill dead-end children when there's nothing else left
Kill dead-end children when there's nothing else left Previously, the postmaster would never try to kill dead-end child processes, even if there were no other processes left. A dead-end backend will eventually exit, when authentication_timeout expires, but if a dead-end backend is the only thing that's preventing the server from shutting down, it seems better to kill it immediately. It's particularly important, if there was a bug in the early startup code that prevented a dead-end child from timing out and exiting normally. Includes a test for that case where a dead-end backend previously prevented the server from shutting down. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/a102f15f-eac4-4ff2-af02-f9ff209ec...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bb861414fea31073f27aaab75a0ceaf3638d7985 Modified Files -- src/backend/postmaster/postmaster.c | 17 +++--- src/test/perl/PostgreSQL/Test/Cluster.pm | 10 +++- src/test/postmaster/meson.build | 1 + src/test/postmaster/t/002_start_stop.pl | 98 4 files changed, 116 insertions(+), 10 deletions(-)
pgsql: Assign a child slot to every postmaster child process
Assign a child slot to every postmaster child process Previously, only backends, autovacuum workers, and background workers had an entry in the PMChildFlags array. With this commit, all postmaster child processes, including all the aux processes, have an entry. Dead-end backends still don't get an entry, though, and other processes that don't touch shared memory will never mark their PMChildFlags entry as active. We now maintain separate freelists for different kinds of child processes. That ensures that there are always slots available for autovacuum and background workers. Previously, pre-authentication backends could prevent autovacuum or background workers from starting up, by using up all the slots. The code to manage the slots in the postmaster process is in a new pmchild.c source file. Because postmaster.c is just so large. Assigning pmsignal slot numbers is now pmchild.c's responsibility. This replaces the PMChildInUse array in pmsignal.c. Some of the comments in postmaster.c still talked about the "stats process", but that was removed in commit 5891c7a8ed. Fix those while we're at it. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/a102f15f-eac4-4ff2-af02-f9ff209ec...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a78af0427015449269fb7d9d8c6057cfcb740149 Modified Files -- src/backend/bootstrap/bootstrap.c | 8 + src/backend/postmaster/Makefile | 1 + src/backend/postmaster/launch_backend.c | 3 + src/backend/postmaster/meson.build | 1 + src/backend/postmaster/pmchild.c| 285 + src/backend/postmaster/postmaster.c | 912 src/backend/postmaster/syslogger.c | 6 +- src/backend/storage/ipc/pmsignal.c | 89 +-- src/backend/storage/lmgr/proc.c | 12 +- src/backend/tcop/postgres.c | 6 + src/include/postmaster/bgworker_internals.h | 2 +- src/include/postmaster/postmaster.h | 45 ++ src/include/postmaster/syslogger.h | 2 +- src/include/storage/pmsignal.h | 4 +- src/tools/pgindent/typedefs.list| 3 +- 15 files changed, 785 insertions(+), 594 deletions(-)
pgsql: libpq: Bail out during SSL/GSS negotiation errors
libpq: Bail out during SSL/GSS negotiation errors This commit changes libpq so that errors reported by the backend during the protocol negotiation for SSL and GSS are discarded by the client, as these may include bytes that could be consumed by the client and write arbitrary bytes to a client's terminal. A failure with the SSL negotiation now leads to an error immediately reported, without a retry on any other methods allowed, like a fallback to a plaintext connection. A failure with GSS discards the error message received, and we allow a fallback as it may be possible that the error is caused by a connection attempt with a pre-11 server, GSS encryption having been introduced in v12. This was a problem only with v17 and newer versions; older versions discard the error message already in this case, assuming a failure caused by a lack of support for GSS encryption. Author: Jacob Champion Reviewed-by: Peter Eisentraut, Heikki Linnakangas, Michael Paquier Security: CVE-2024-10977 Backpatch-through: 12 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/67d28bd02ec06f5056754bc295f57d2dd2bbd749 Modified Files -- doc/src/sgml/protocol.sgml| 21 +++-- src/interfaces/libpq/fe-connect.c | 14 +- 2 files changed, 16 insertions(+), 19 deletions(-)
pgsql: libpq: Bail out during SSL/GSS negotiation errors
libpq: Bail out during SSL/GSS negotiation errors This commit changes libpq so that errors reported by the backend during the protocol negotiation for SSL and GSS are discarded by the client, as these may include bytes that could be consumed by the client and write arbitrary bytes to a client's terminal. A failure with the SSL negotiation now leads to an error immediately reported, without a retry on any other methods allowed, like a fallback to a plaintext connection. A failure with GSS discards the error message received, and we allow a fallback as it may be possible that the error is caused by a connection attempt with a pre-11 server, GSS encryption having been introduced in v12. This was a problem only with v17 and newer versions; older versions discard the error message already in this case, assuming a failure caused by a lack of support for GSS encryption. Author: Jacob Champion Reviewed-by: Peter Eisentraut, Heikki Linnakangas, Michael Paquier Security: CVE-2024-10977 Backpatch-through: 12 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7b49707b72612ef068ce9275b9b6da104f1960f3 Modified Files -- doc/src/sgml/protocol.sgml| 21 +++-- src/interfaces/libpq/fe-connect.c | 15 ++- 2 files changed, 17 insertions(+), 19 deletions(-)
pgsql: libpq: Bail out during SSL/GSS negotiation errors
libpq: Bail out during SSL/GSS negotiation errors This commit changes libpq so that errors reported by the backend during the protocol negotiation for SSL and GSS are discarded by the client, as these may include bytes that could be consumed by the client and write arbitrary bytes to a client's terminal. A failure with the SSL negotiation now leads to an error immediately reported, without a retry on any other methods allowed, like a fallback to a plaintext connection. A failure with GSS discards the error message received, and we allow a fallback as it may be possible that the error is caused by a connection attempt with a pre-11 server, GSS encryption having been introduced in v12. This was a problem only with v17 and newer versions; older versions discard the error message already in this case, assuming a failure caused by a lack of support for GSS encryption. Author: Jacob Champion Reviewed-by: Peter Eisentraut, Heikki Linnakangas, Michael Paquier Security: CVE-2024-10977 Backpatch-through: 12 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d2c3e31c13a6820980c2c6019f0b8f9f0b63ae6e Modified Files -- doc/src/sgml/protocol.sgml| 21 +++-- src/interfaces/libpq/fe-connect.c | 15 ++- 2 files changed, 17 insertions(+), 19 deletions(-)
pgsql: libpq: Bail out during SSL/GSS negotiation errors
libpq: Bail out during SSL/GSS negotiation errors This commit changes libpq so that errors reported by the backend during the protocol negotiation for SSL and GSS are discarded by the client, as these may include bytes that could be consumed by the client and write arbitrary bytes to a client's terminal. A failure with the SSL negotiation now leads to an error immediately reported, without a retry on any other methods allowed, like a fallback to a plaintext connection. A failure with GSS discards the error message received, and we allow a fallback as it may be possible that the error is caused by a connection attempt with a pre-11 server, GSS encryption having been introduced in v12. This was a problem only with v17 and newer versions; older versions discard the error message already in this case, assuming a failure caused by a lack of support for GSS encryption. Author: Jacob Champion Reviewed-by: Peter Eisentraut, Heikki Linnakangas, Michael Paquier Security: CVE-2024-10977 Backpatch-through: 12 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a5cc4c66719be2ae1eebe92ad97727dc905bbc6d Modified Files -- doc/src/sgml/protocol.sgml| 21 +++-- src/interfaces/libpq/fe-connect.c | 34 ++ 2 files changed, 21 insertions(+), 34 deletions(-)
pgsql: libpq: Bail out during SSL/GSS negotiation errors
libpq: Bail out during SSL/GSS negotiation errors This commit changes libpq so that errors reported by the backend during the protocol negotiation for SSL and GSS are discarded by the client, as these may include bytes that could be consumed by the client and write arbitrary bytes to a client's terminal. A failure with the SSL negotiation now leads to an error immediately reported, without a retry on any other methods allowed, like a fallback to a plaintext connection. A failure with GSS discards the error message received, and we allow a fallback as it may be possible that the error is caused by a connection attempt with a pre-11 server, GSS encryption having been introduced in v12. This was a problem only with v17 and newer versions; older versions discard the error message already in this case, assuming a failure caused by a lack of support for GSS encryption. Author: Jacob Champion Reviewed-by: Peter Eisentraut, Heikki Linnakangas, Michael Paquier Security: CVE-2024-10977 Backpatch-through: 12 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bf8835ea9717df50230c12133cff1b486dcc57be Modified Files -- doc/src/sgml/protocol.sgml | 21 ++--- src/interfaces/libpq/fe-connect.c | 34 +++--- src/interfaces/libpq/t/005_negotiate_encryption.pl | 2 +- 3 files changed, 22 insertions(+), 35 deletions(-)
pgsql: libpq: Bail out during SSL/GSS negotiation errors
libpq: Bail out during SSL/GSS negotiation errors This commit changes libpq so that errors reported by the backend during the protocol negotiation for SSL and GSS are discarded by the client, as these may include bytes that could be consumed by the client and write arbitrary bytes to a client's terminal. A failure with the SSL negotiation now leads to an error immediately reported, without a retry on any other methods allowed, like a fallback to a plaintext connection. A failure with GSS discards the error message received, and we allow a fallback as it may be possible that the error is caused by a connection attempt with a pre-11 server, GSS encryption having been introduced in v12. This was a problem only with v17 and newer versions; older versions discard the error message already in this case, assuming a failure caused by a lack of support for GSS encryption. Author: Jacob Champion Reviewed-by: Peter Eisentraut, Heikki Linnakangas, Michael Paquier Security: CVE-2024-10977 Backpatch-through: 12 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2a951ef0aace58026c31b9a88aeeda19c9af4205 Modified Files -- doc/src/sgml/protocol.sgml| 21 +++-- src/interfaces/libpq/fe-connect.c | 15 ++- 2 files changed, 17 insertions(+), 19 deletions(-)
pgsql: libpq: Bail out during SSL/GSS negotiation errors
libpq: Bail out during SSL/GSS negotiation errors This commit changes libpq so that errors reported by the backend during the protocol negotiation for SSL and GSS are discarded by the client, as these may include bytes that could be consumed by the client and write arbitrary bytes to a client's terminal. A failure with the SSL negotiation now leads to an error immediately reported, without a retry on any other methods allowed, like a fallback to a plaintext connection. A failure with GSS discards the error message received, and we allow a fallback as it may be possible that the error is caused by a connection attempt with a pre-11 server, GSS encryption having been introduced in v12. This was a problem only with v17 and newer versions; older versions discard the error message already in this case, assuming a failure caused by a lack of support for GSS encryption. Author: Jacob Champion Reviewed-by: Peter Eisentraut, Heikki Linnakangas, Michael Paquier Security: CVE-2024-10977 Backpatch-through: 12 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e6c9454764d880ee30735aa8c1e05d3674722ff9 Modified Files -- doc/src/sgml/protocol.sgml| 21 +++-- src/interfaces/libpq/fe-connect.c | 15 ++- 2 files changed, 17 insertions(+), 19 deletions(-)
pgsql: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2024-10976, CVE-2024-10977, CVE-2024-10978, CVE-2024-10979 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/575d673fe78f76e396ea7eb8160c30d96ccfea0f Modified Files -- doc/src/sgml/release-14.sgml | 180 ++- 1 file changed, 179 insertions(+), 1 deletion(-)
pgsql: Parallel workers use AuthenticatedUserId for connection privileg
Parallel workers use AuthenticatedUserId for connection privilege checks. Commit 5a2fed911 had an unexpected side-effect: the parallel worker launched for the new test case would fail if it couldn't use a superuser-reserved connection slot. The reason that test failed while all our pre-existing ones worked is that the connection privilege tests in InitPostgres had been based on the superuserness of the leader's AuthenticatedUserId, but after the rearrangements of 5a2fed911 we were testing the superuserness of CurrentUserId, which the new test case deliberately made to be a non-superuser. This all seems very accidental and probably not the behavior we really want, but a security patch is no time to be redesigning things. Pending some discussion about desirable semantics, hack it so that InitPostgres continues to pay attention to the superuserness of AuthenticatedUserId when starting a parallel worker. Nathan Bossart and Tom Lane, per buildfarm member sawshark. Security: CVE-2024-10978 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/00b94e8e2f99a8ed1d7f854838234ce37f582da0 Modified Files -- src/backend/utils/init/postinit.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-)
pgsql: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2024-10976, CVE-2024-10977, CVE-2024-10978, CVE-2024-10979 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/03dc78ff644ca0c090cb4cdbf8fba64230e54238 Modified Files -- doc/src/sgml/release-16.sgml | 181 ++- 1 file changed, 180 insertions(+), 1 deletion(-)
pgsql: Parallel workers use AuthenticatedUserId for connection privileg
Parallel workers use AuthenticatedUserId for connection privilege checks. Commit 5a2fed911 had an unexpected side-effect: the parallel worker launched for the new test case would fail if it couldn't use a superuser-reserved connection slot. The reason that test failed while all our pre-existing ones worked is that the connection privilege tests in InitPostgres had been based on the superuserness of the leader's AuthenticatedUserId, but after the rearrangements of 5a2fed911 we were testing the superuserness of CurrentUserId, which the new test case deliberately made to be a non-superuser. This all seems very accidental and probably not the behavior we really want, but a security patch is no time to be redesigning things. Pending some discussion about desirable semantics, hack it so that InitPostgres continues to pay attention to the superuserness of AuthenticatedUserId when starting a parallel worker. Nathan Bossart and Tom Lane, per buildfarm member sawshark. Security: CVE-2024-10978 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/73c9f91a1b6d3753451993c5f06ba4b5ccc1f127 Modified Files -- src/backend/utils/init/postinit.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-)
pgsql: Block environment variable mutations from trusted PL/Perl.
Block environment variable mutations from trusted PL/Perl. Many process environment variables (e.g. PATH), bypass the containment expected of a trusted PL. Hence, trusted PLs must not offer features that achieve setenv(). Otherwise, an attacker having USAGE privilege on the language often can achieve arbitrary code execution, even if the attacker lacks a database server operating system user. To fix PL/Perl, replace trusted PL/Perl %ENV with a tied hash that just replaces each modification attempt with a warning. Sites that reach these warnings should evaluate the application-specific implications of proceeding without the environment modification: Can the application reasonably proceed without the modification? If no, switch to plperlu or another approach. If yes, the application should change the code to stop attempting environment modifications. If that's too difficult, add "untie %main::ENV" in any code executed before the warning. For example, one might add it to the start of the affected function or even to the plperl.on_plperl_init setting. In passing, link to Perl's guidance about the Perl features behind the security posture of PL/Perl. Back-patch to v12 (all supported versions). Andrew Dunstan and Noah Misch Security: CVE-2024-10979 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b7e3a52a877cffb42ec7208232e30a8e44231e01 Modified Files -- doc/src/sgml/plperl.sgml | 13 src/pl/plperl/GNUmakefile | 4 +-- src/pl/plperl/expected/plperl_env.out | 53 src/pl/plperl/meson.build | 2 ++ src/pl/plperl/plc_trusted.pl | 24 +++ src/pl/plperl/sql/plperl_env.sql | 58 +++ src/test/regress/regress.c| 24 +++ 7 files changed, 176 insertions(+), 2 deletions(-)
pgsql: Block environment variable mutations from trusted PL/Perl.
Block environment variable mutations from trusted PL/Perl. Many process environment variables (e.g. PATH), bypass the containment expected of a trusted PL. Hence, trusted PLs must not offer features that achieve setenv(). Otherwise, an attacker having USAGE privilege on the language often can achieve arbitrary code execution, even if the attacker lacks a database server operating system user. To fix PL/Perl, replace trusted PL/Perl %ENV with a tied hash that just replaces each modification attempt with a warning. Sites that reach these warnings should evaluate the application-specific implications of proceeding without the environment modification: Can the application reasonably proceed without the modification? If no, switch to plperlu or another approach. If yes, the application should change the code to stop attempting environment modifications. If that's too difficult, add "untie %main::ENV" in any code executed before the warning. For example, one might add it to the start of the affected function or even to the plperl.on_plperl_init setting. In passing, link to Perl's guidance about the Perl features behind the security posture of PL/Perl. Back-patch to v12 (all supported versions). Andrew Dunstan and Noah Misch Security: CVE-2024-10979 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2ab12d860e51e468703a2777b3759b7a61639df2 Modified Files -- doc/src/sgml/plperl.sgml | 13 + src/pl/plperl/GNUmakefile | 4 +-- src/pl/plperl/input/plperl_env.source | 52 ++ src/pl/plperl/output/plperl_env.source | 49 src/pl/plperl/plc_trusted.pl | 24 src/test/regress/regress.c | 24 6 files changed, 164 insertions(+), 2 deletions(-)
pgsql: Ensure cached plans are correctly marked as dependent on role.
Ensure cached plans are correctly marked as dependent on role. If a CTE, subquery, sublink, security invoker view, or coercion projection references a table with row-level security policies, we neglected to mark the plan as potentially dependent on which role is executing it. This could lead to later executions in the same session returning or hiding rows that should have been hidden or returned instead. Reported-by: Wolfgang Walther Reviewed-by: Noah Misch Security: CVE-2024-10976 Backpatch-through: 12 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/952ff31e2a89e8ca79ecb12d61fddbeac3d89176 Modified Files -- src/backend/executor/functions.c | 6 +++ src/backend/rewrite/rewriteHandler.c | 67 +++--- src/test/regress/expected/rowsecurity.out | 78 +++ src/test/regress/sql/rowsecurity.sql | 44 + src/tools/pgindent/typedefs.list | 1 + 5 files changed, 190 insertions(+), 6 deletions(-)
pgsql: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2024-10976, CVE-2024-10977, CVE-2024-10978, CVE-2024-10979 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b83b358b1bac61ca46af995a3da83cc515a434c6 Modified Files -- doc/src/sgml/release-15.sgml | 179 ++- 1 file changed, 178 insertions(+), 1 deletion(-)
pgsql: Block environment variable mutations from trusted PL/Perl.
Block environment variable mutations from trusted PL/Perl. Many process environment variables (e.g. PATH), bypass the containment expected of a trusted PL. Hence, trusted PLs must not offer features that achieve setenv(). Otherwise, an attacker having USAGE privilege on the language often can achieve arbitrary code execution, even if the attacker lacks a database server operating system user. To fix PL/Perl, replace trusted PL/Perl %ENV with a tied hash that just replaces each modification attempt with a warning. Sites that reach these warnings should evaluate the application-specific implications of proceeding without the environment modification: Can the application reasonably proceed without the modification? If no, switch to plperlu or another approach. If yes, the application should change the code to stop attempting environment modifications. If that's too difficult, add "untie %main::ENV" in any code executed before the warning. For example, one might add it to the start of the affected function or even to the plperl.on_plperl_init setting. In passing, link to Perl's guidance about the Perl features behind the security posture of PL/Perl. Back-patch to v12 (all supported versions). Andrew Dunstan and Noah Misch Security: CVE-2024-10979 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e428cd058f0bebb5782b0c263565b0ad088e9650 Modified Files -- doc/src/sgml/plperl.sgml | 13 + src/pl/plperl/GNUmakefile | 4 +-- src/pl/plperl/input/plperl_env.source | 52 ++ src/pl/plperl/output/plperl_env.source | 49 src/pl/plperl/plc_trusted.pl | 24 src/test/regress/regress.c | 24 6 files changed, 164 insertions(+), 2 deletions(-)
pgsql: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2024-10976, CVE-2024-10977, CVE-2024-10978, CVE-2024-10979 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/052aa02971f2dd476c14689033727a0b8563d5d2 Modified Files -- doc/src/sgml/release-17.sgml | 181 ++- 1 file changed, 179 insertions(+), 2 deletions(-)
pgsql: Ensure cached plans are correctly marked as dependent on role.
Ensure cached plans are correctly marked as dependent on role. If a CTE, subquery, sublink, security invoker view, or coercion projection references a table with row-level security policies, we neglected to mark the plan as potentially dependent on which role is executing it. This could lead to later executions in the same session returning or hiding rows that should have been hidden or returned instead. Reported-by: Wolfgang Walther Reviewed-by: Noah Misch Security: CVE-2024-10976 Backpatch-through: 12 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6db5ea8de8ce15897b706009aaf701d23bd65b23 Modified Files -- src/backend/executor/functions.c | 6 ++ src/backend/rewrite/rewriteHandler.c | 67 ++-- src/test/regress/expected/rowsecurity.out | 100 ++ src/test/regress/sql/rowsecurity.sql | 58 + src/tools/pgindent/typedefs.list | 1 + 5 files changed, 226 insertions(+), 6 deletions(-)
pgsql: Ensure cached plans are correctly marked as dependent on role.
Ensure cached plans are correctly marked as dependent on role. If a CTE, subquery, sublink, security invoker view, or coercion projection references a table with row-level security policies, we neglected to mark the plan as potentially dependent on which role is executing it. This could lead to later executions in the same session returning or hiding rows that should have been hidden or returned instead. Reported-by: Wolfgang Walther Reviewed-by: Noah Misch Security: CVE-2024-10976 Backpatch-through: 12 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cd7ab57532bb4fbf2e636b1f7d132e6e2d9ac5fc Modified Files -- src/backend/executor/functions.c | 6 ++ src/backend/rewrite/rewriteHandler.c | 67 ++-- src/test/regress/expected/rowsecurity.out | 100 ++ src/test/regress/sql/rowsecurity.sql | 58 + src/tools/pgindent/typedefs.list | 1 + 5 files changed, 226 insertions(+), 6 deletions(-)
pgsql: Parallel workers use AuthenticatedUserId for connection privileg
Parallel workers use AuthenticatedUserId for connection privilege checks. Commit 5a2fed911 had an unexpected side-effect: the parallel worker launched for the new test case would fail if it couldn't use a superuser-reserved connection slot. The reason that test failed while all our pre-existing ones worked is that the connection privilege tests in InitPostgres had been based on the superuserness of the leader's AuthenticatedUserId, but after the rearrangements of 5a2fed911 we were testing the superuserness of CurrentUserId, which the new test case deliberately made to be a non-superuser. This all seems very accidental and probably not the behavior we really want, but a security patch is no time to be redesigning things. Pending some discussion about desirable semantics, hack it so that InitPostgres continues to pay attention to the superuserness of AuthenticatedUserId when starting a parallel worker. Nathan Bossart and Tom Lane, per buildfarm member sawshark. Security: CVE-2024-10978 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f4f5d27d87247da1ec7e5a6e7990a22ffba9f63a Modified Files -- src/backend/utils/init/postinit.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-)
pgsql: Parallel workers use AuthenticatedUserId for connection privileg
Parallel workers use AuthenticatedUserId for connection privilege checks. Commit 5a2fed911 had an unexpected side-effect: the parallel worker launched for the new test case would fail if it couldn't use a superuser-reserved connection slot. The reason that test failed while all our pre-existing ones worked is that the connection privilege tests in InitPostgres had been based on the superuserness of the leader's AuthenticatedUserId, but after the rearrangements of 5a2fed911 we were testing the superuserness of CurrentUserId, which the new test case deliberately made to be a non-superuser. This all seems very accidental and probably not the behavior we really want, but a security patch is no time to be redesigning things. Pending some discussion about desirable semantics, hack it so that InitPostgres continues to pay attention to the superuserness of AuthenticatedUserId when starting a parallel worker. Nathan Bossart and Tom Lane, per buildfarm member sawshark. Security: CVE-2024-10978 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/95f5a523729f6814c8757860d9a2264148b7b0df Modified Files -- src/backend/utils/init/postinit.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-)
pgsql: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2024-10976, CVE-2024-10977, CVE-2024-10978, CVE-2024-10979 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/aee114bf1c84368db9e50ba4e7340ce632f89e19 Modified Files -- doc/src/sgml/release-12.sgml | 178 +++ 1 file changed, 178 insertions(+)
pgsql: Parallel workers use AuthenticatedUserId for connection privileg
Parallel workers use AuthenticatedUserId for connection privilege checks. Commit 5a2fed911 had an unexpected side-effect: the parallel worker launched for the new test case would fail if it couldn't use a superuser-reserved connection slot. The reason that test failed while all our pre-existing ones worked is that the connection privilege tests in InitPostgres had been based on the superuserness of the leader's AuthenticatedUserId, but after the rearrangements of 5a2fed911 we were testing the superuserness of CurrentUserId, which the new test case deliberately made to be a non-superuser. This all seems very accidental and probably not the behavior we really want, but a security patch is no time to be redesigning things. Pending some discussion about desirable semantics, hack it so that InitPostgres continues to pay attention to the superuserness of AuthenticatedUserId when starting a parallel worker. Nathan Bossart and Tom Lane, per buildfarm member sawshark. Security: CVE-2024-10978 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dc7378793add3c3d9a40ec2118d92bd719acab97 Modified Files -- src/backend/utils/init/postinit.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-)
pgsql: Parallel workers use AuthenticatedUserId for connection privileg
Parallel workers use AuthenticatedUserId for connection privilege checks. Commit 5a2fed911 had an unexpected side-effect: the parallel worker launched for the new test case would fail if it couldn't use a superuser-reserved connection slot. The reason that test failed while all our pre-existing ones worked is that the connection privilege tests in InitPostgres had been based on the superuserness of the leader's AuthenticatedUserId, but after the rearrangements of 5a2fed911 we were testing the superuserness of CurrentUserId, which the new test case deliberately made to be a non-superuser. This all seems very accidental and probably not the behavior we really want, but a security patch is no time to be redesigning things. Pending some discussion about desirable semantics, hack it so that InitPostgres continues to pay attention to the superuserness of AuthenticatedUserId when starting a parallel worker. Nathan Bossart and Tom Lane, per buildfarm member sawshark. Security: CVE-2024-10978 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0edad8654848affe0786c798aea9e1a43dde54bc Modified Files -- src/backend/utils/init/postinit.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-)
pgsql: Pass MyPMChildSlot as an explicit argument to child process
Pass MyPMChildSlot as an explicit argument to child process All the other global variables passed from postmaster to child have the same value in all the processes, while MyPMChildSlot is more like a parameter to each child process. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/a102f15f-eac4-4ff2-af02-f9ff209ec...@iki.fi Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5b007868577ae18d419c01ee739e5674fa8b2acf Modified Files -- src/backend/postmaster/launch_backend.c | 37 + src/backend/postmaster/postmaster.c | 10 - src/backend/postmaster/syslogger.c | 7 --- src/include/postmaster/postmaster.h | 1 + 4 files changed, 33 insertions(+), 22 deletions(-)
pgsql: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2024-10976, CVE-2024-10977, CVE-2024-10978, CVE-2024-10979 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b3db5fdb05b6ca499f75d0ecf290dbd057bfb075 Modified Files -- doc/src/sgml/release-13.sgml | 180 ++- 1 file changed, 179 insertions(+), 1 deletion(-)
pgsql: Fix improper interactions between session_authorization and role
Fix improper interactions between session_authorization and role.
The SQL spec mandates that SET SESSION AUTHORIZATION implies
SET ROLE NONE. We tried to implement that within the lowest-level
functions that manipulate these settings, but that was a bad idea.
In particular, guc.c assumes that it doesn't matter in what order
it applies GUC variable updates, but that was not the case for these
two variables. This problem, compounded by some hackish attempts to
work around it, led to some security-grade issues:
* Rolling back a transaction that had done SET SESSION AUTHORIZATION
would revert to SET ROLE NONE, even if that had not been the previous
state, so that the effective user ID might now be different from what
it had been.
* The same for SET SESSION AUTHORIZATION in a function SET clause.
* If a parallel worker inspected current_setting('role'), it saw
"none" even when it should see something else.
Also, although the parallel worker startup code intended to cope
with the current role's pg_authid row having disappeared, its
implementation of that was incomplete so it would still fail.
Fix by fully separating the miscinit.c functions that assign
session_authorization from those that assign role. To implement the
spec's requirement, teach set_config_option itself to perform "SET
ROLE NONE" when it sets session_authorization. (This is undoubtedly
ugly, but the alternatives seem worse. In particular, there's no way
to do it within assign_session_authorization without incompatible
changes in the API for GUC assign hooks.) Also, improve
ParallelWorkerMain to directly set all the relevant user-ID variables
instead of relying on some of them to get set indirectly. That
allows us to survive not finding the pg_authid row during worker
startup.
In v16 and earlier, this includes back-patching 9987a7bf3 which
fixed a violation of GUC coding rules: SetSessionAuthorization
is not an appropriate place to be throwing errors from.
Security: CVE-2024-10978
Branch
--
REL_15_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/a5d2e6205f716c79ecfb15eb1aae75bae3f8daa9
Modified Files
--
src/backend/access/transam/parallel.c| 36 +--
src/backend/commands/variable.c | 101 ++--
src/backend/utils/init/miscinit.c| 157 ++-
src/backend/utils/misc/guc.c | 43 +++--
src/include/miscadmin.h | 3 +
src/test/regress/expected/privileges.out | 67 +
src/test/regress/sql/privileges.sql | 33 +++
7 files changed, 330 insertions(+), 110 deletions(-)
pgsql: Block environment variable mutations from trusted PL/Perl.
Block environment variable mutations from trusted PL/Perl. Many process environment variables (e.g. PATH), bypass the containment expected of a trusted PL. Hence, trusted PLs must not offer features that achieve setenv(). Otherwise, an attacker having USAGE privilege on the language often can achieve arbitrary code execution, even if the attacker lacks a database server operating system user. To fix PL/Perl, replace trusted PL/Perl %ENV with a tied hash that just replaces each modification attempt with a warning. Sites that reach these warnings should evaluate the application-specific implications of proceeding without the environment modification: Can the application reasonably proceed without the modification? If no, switch to plperlu or another approach. If yes, the application should change the code to stop attempting environment modifications. If that's too difficult, add "untie %main::ENV" in any code executed before the warning. For example, one might add it to the start of the affected function or even to the plperl.on_plperl_init setting. In passing, link to Perl's guidance about the Perl features behind the security posture of PL/Perl. Back-patch to v12 (all supported versions). Andrew Dunstan and Noah Misch Security: CVE-2024-10979 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3ebcfa54db3309651d8f1d3be6451a8449f6c6ec Modified Files -- doc/src/sgml/plperl.sgml | 13 src/pl/plperl/GNUmakefile | 4 +-- src/pl/plperl/expected/plperl_env.out | 53 src/pl/plperl/meson.build | 2 ++ src/pl/plperl/plc_trusted.pl | 24 +++ src/pl/plperl/sql/plperl_env.sql | 58 +++ src/test/regress/regress.c| 23 ++ 7 files changed, 175 insertions(+), 2 deletions(-)
