Package: pgpool2 / 4.3.5-1+deb12u1
Metadata
| Package | Version | Patches format |
|---|---|---|
| pgpool2 | 4.3.5-1+deb12u1 | 3.0 (quilt) |
Patch series
view the series file| Patch | File delta | Description |
|---|---|---|
| pgpool2 debian config.patch | (download) |
src/include/pool.h |
6 3 + 3 - 0 ! |
pgpool2 debian config |
| sbin paths | (download) |
src/test/pgpool_setup.in |
4 2 + 2 - 0 ! |
pgpool_setup + pg_md5 path https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877851 |
| CVE 2024 45624_1.patch | (download) |
doc.ja/src/sgml/memcache.sgml |
17 17 + 0 - 0 ! |
[patch] fix multiple query cache vulnerabilities (cve-2024-45624). When the query cache feature is enabled, it was possible that a user can read rows from tables that should not be visible for the user through 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. - 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, it was possible for the user B to retrieve rows which should not be visible from the user B. - 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 to retrieve the rows through the query cache. Besides the vulnerabilities, there were multiple bugs with the query cache feature. - If query cache is created for a row security enabled table for a user, and then ALTER DATABASE BYPASSRLS or ALTER ROLE BYPASSRLS disable the row security of the table, subsequent SELECT still returns the same rows as before through the query cache. - If query cache is created for a table for a user, and then ALTER TABLE SET SCHEMA changes the search path to not allow to access the table, subsequent SELECT still returns the rows as before through the query cache. To fix above, following changes are made: - Do not allow to create query cache/use query cache for row security enabled tables (even if the table is included in cache_safe_memqcache_table_list). - Do not allow to create query cache/use query cache if SET ROLE/SET AUTHORIZATION is executed in the session (query cache invalidation is performed when a table is modified as usual). - Remove entire query cache if REVOKE/ALTER DATABASE/ALTER TABLE/ALTER ROLE is executed. If the command is executed in an explicit transaction, do not create query cache/use query cache until the transaction gets committed (query cache invalidation is performed when a table is modified as usual). If the transaction is aborted, do not remove query cache. Patch is created by Tatsuo Ishii. Backpatch-through: v4.1 |
| CVE 2024 45624_2.patch | (download) |
doc.ja/src/sgml/memcache.sgml |
2 1 + 1 - 0 ! |
[patch] optimize query cache invalidation for alter role. Commit 6b7d585eb1c693e4ffb5b8e6ed9aa0f067fa1b89 invalidates query cache if any ALTER ROLE/USER statement is used. Actually this is an overkill. Because following queries do not affect the privilege of the role. - ALTER ROLE user WITH [ENCRYPTED] PASSWORD - ALTER ROLE user WITH CONNECTION LIMIT So do not invalidate query cache if those commands are used. Backpatch-through: v4.1 Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2024-October/004532.html |
| CVE 2025 46801.patch | (download) |
doc.ja/src/sgml/client-auth.sgml |
45 23 + 22 - 0 ! |
[patch 1/1] fix incorrect client authentication in some cases. If enable_pool_hba = on, it's auth method is "password", no password is registered in pool_passwd, and auth method in pg_hba.conf is "scram-sha-256" or "md5", for the first time when a client connects to pgpool, authentication is performed as expected. But if a client connects to the cached connection, any password from the client is accepted. authenticate_frontend() asks password to the client and stores it in frontend->password. When pgpool authenticate backend, authenticate_frontend_SCRAM() or authenticate_frontend_md5() is called depending on pg_hba.conf setting. authenticate_frontend_*() calls get_auth_password() to get backend cached password but it mistakenly returned frontend->password if pool_passwd does not have an entry for the user. Then authenticate_frontend_*() tries to challenge based on frontend->password. As a result, they compared frontend->password itself, which always succeed. To fix this, when get_auth_password() is called with reauth parameter being non 0, return backend->password. Also if enable_pool_hba = off, in some cases a client is not asked password for the first time, or when a client connects to cached connection, even if it should be. If pool_hba.conf is disabled, get_backend_connection() does not call Client_authentication(), thus frontend->password is not set. Then pool_do_reauth() calls do_clear_text_password(). It should have called authenticate_frontend_clear_text() to get a password from the client, but a mistake in a if statement prevented it. The mistake was fixed in this commit. Pgpool-II versions affected: v4.0 or later. Also this commit does followings: - Remove single PostgreSQL code path to simplify the authentication code. As a result, following cases are no more Ok. - Remove crypt authentication support for frontend and backend. The feature had not been documented and never tested. Moreover crypt authentication was removed long time ago in PostgreSQL (8.4, 2009). - Add new regression test "040.client_auth". The test performs exhaustive client authentication tests using a test specification file formatted in CSV. The csv files have 7 fields: username: the username used for the test case pool_hba.conf: takes "scram", "md5", "password", "pam", "ldap" or "off". If "scram", "md5" , "password", "pam" or "ldap", the user will have an entry in pool_hba.conf accordingly. If "off", enable_pool_hba.conf will be off. allow_clear_text_frontend_auth: takes "on" or "off". pool_passwd: takes "AES", "md5" or "off". If "AES" or "md5" the user's password will be stored in pool_passwd using ASE256 or md5 encryption method accordingly. If "off" is specified, no entry will be created. pg_hba.conf: almost same as pool_hba.conf except this is for pg_hba.conf. expected: takes "ok" or "fail". If ok, the authentication is expected to be succeeded. If failed, the test is regarded as failed. "fail" is opposite. The authentication is expected to be failed. If succeeds, the test regarded as failed. comment: arbitrary comment By changing these fields, we can easily modify or add test cases. The merit of this method is possible higher test coverage. For human, it is easier to find uncovered test cases in a table than in a program code. Backpatch-through: v4.2 The patch was created by Tatsuo Ishii. |