| pgpool-II 4.1.22 Documentation | |||
|---|---|---|---|
| Prev | Up | Appendix A. Release Notes | Next |
Release Date: 2024-09-09
This release contains a security fix.
When the query cache (Section 5.12) feature is enabled, it was possible that a database user can read rows from tables that should not be visible for the user through query cache (CVE-2024-45624).
All versions of Pgpool-II older than 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22, and all older versions that has the query cache feature (the query cache feature was implemented in 3.2) are affected by the vulnerability.
If query cache is created for a table for a user, and then the access right of the table is revoked from the user by REVOKE command, still it was possible for the user to access the table which the user does not have the access right through the query cache.
If query cache is created for a table for user A, and then other user B accesses the table via SET ROLE or SET SESSION_AUTHORIZATION in the same session, still it was possible for the user B to access the table which B does not have the access right through the query cache.
If query cache is created for a row security enabled table for user A, and then other user B accesses the table via SET ROLE or SET SESSION_AUTHORIZATION in the same session, it was possible for the user B to retrieve rows which should not be visible from the user B through the query cache.
It is strongly recommend to upgrade to Pgpool-II 4.5.4, 4.4.9, 4.3.12, 4.2.19 and 4.1.22 or later. Or you should better turn off the query cache feature.
Note that to fix the vulnerability, some commands (ALTER DATABASE, ALTER ROLE, ALTER TABLE, REVOKE) now invalidate whole query cache data. This may affect the performance when using the query cache feature.
Back port notice_per_node_statement. (Tatsuo Ishii)
This is mainly for testing. Backpatch-through: v4.1
Discussion: [pgpool-hackers: 4504]
Fix bugs in replication mode and snapshot isolation mode. (Tatsuo Ishii)
The following bugs was fixed:
In replication mode and snapshot isolation mode when a command finishes, Pgpool-II waits for a ready for query message but forgot that some commands (for example SET ROLE) produces a parameter status message. As a result Pgpool-II errors out that other message arrives before the ready for query message.
If previous query produces parameter status message, subsequent
parse() needs to read and process it because
it wants to read Ready for query message which is supposed to follow
the parameter status message.
However when ParameterStatus() gets called,
the query in progress flag was set and it was possible that only
one of parameter status message from backend was processed if the
query processed in this parse() call is load
balanced. It is likely that the parameter status message comes from
all live backend because they are generated by SET
command, and SET command are sent to all live backend
in replication mode and snapshot isolation mode. So unset the query in
progress flag before calling ParameterStatus().