pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Fix improper interactions between session_authorization and role
7+ messages / 1 participants
[nested] [flat]
* pgsql: Fix improper interactions between session_authorization and role
@ 2024-11-11 15:30 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 7+ messages in thread
From: Tom Lane @ 2024-11-11 15:30 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix improper interactions between session_authorization and role
@ 2024-11-11 15:30 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 7+ messages in thread
From: Tom Lane @ 2024-11-11 15:30 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix improper interactions between session_authorization and role
@ 2024-11-11 15:30 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 7+ messages in thread
From: Tom Lane @ 2024-11-11 15:30 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix improper interactions between session_authorization and role
@ 2024-11-11 15:30 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 7+ messages in thread
From: Tom Lane @ 2024-11-11 15:30 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix improper interactions between session_authorization and role
@ 2024-11-11 15:30 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 7+ messages in thread
From: Tom Lane @ 2024-11-11 15:30 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix improper interactions between session_authorization and role
@ 2024-11-11 15:30 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 7+ messages in thread
From: Tom Lane @ 2024-11-11 15:30 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix improper interactions between session_authorization and role
@ 2024-11-11 15:30 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 7+ messages in thread
From: Tom Lane @ 2024-11-11 15:30 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2024-11-11 15:30 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-11-11 15:30 pgsql: Fix improper interactions between session_authorization and role Tom Lane <tgl@sss.pgh.pa.us>
2024-11-11 15:30 pgsql: Fix improper interactions between session_authorization and role Tom Lane <tgl@sss.pgh.pa.us>
2024-11-11 15:30 pgsql: Fix improper interactions between session_authorization and role Tom Lane <tgl@sss.pgh.pa.us>
2024-11-11 15:30 pgsql: Fix improper interactions between session_authorization and role Tom Lane <tgl@sss.pgh.pa.us>
2024-11-11 15:30 pgsql: Fix improper interactions between session_authorization and role Tom Lane <tgl@sss.pgh.pa.us>
2024-11-11 15:30 pgsql: Fix improper interactions between session_authorization and role Tom Lane <tgl@sss.pgh.pa.us>
2024-11-11 15:30 pgsql: Fix improper interactions between session_authorization and role Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox