From 594b6f1b2f60e9abb754ed2e609cb18ce0a8fda8 Mon Sep 17 00:00:00 2001 From: Bo Peng Date: Sat, 7 Sep 2024 23:02:19 +0900 Subject: [PATCH] Doc: add release notes. --- doc.ja/src/sgml/release-4.1.sgml | 109 +++++++++++++++++++++++ doc.ja/src/sgml/release-4.2.sgml | 109 +++++++++++++++++++++++ doc.ja/src/sgml/release-4.3.sgml | 109 +++++++++++++++++++++++ doc.ja/src/sgml/release-4.4.sgml | 109 +++++++++++++++++++++++ doc/src/sgml/release-4.1.sgml | 143 +++++++++++++++++++++++++++++++ doc/src/sgml/release-4.2.sgml | 143 +++++++++++++++++++++++++++++++ doc/src/sgml/release-4.3.sgml | 143 +++++++++++++++++++++++++++++++ doc/src/sgml/release-4.4.sgml | 143 +++++++++++++++++++++++++++++++ 8 files changed, 1008 insertions(+) diff --git a/doc.ja/src/sgml/release-4.1.sgml b/doc.ja/src/sgml/release-4.1.sgml index ebe8259b2..c54ad0048 100644 --- a/doc.ja/src/sgml/release-4.1.sgml +++ b/doc.ja/src/sgml/release-4.1.sgml @@ -1,6 +1,115 @@ + + リリース 4.1.22 + + リリース日 + 2024-09-09 + + + + 概要 + + このリリースには、セキュリティ修正が含まれています。 + + + クエリキャッシュ機能（）が有効な時に、データベースユーザがクエリキャッシュ経由で本来読み出せない行を読むことが可能でした。(CVE-2024-45624) + + + 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22より古く、クエリキャッシュ機能を持つすべてのバージョン(クエリキャッシュ機能は3.2で実装されました)がこの脆弱性の影響を受けます。 + + + + + + あるユーザのクエリキャッシュがテーブルに対して作成されていると、そのテーブルへのアクセス権がREVOKEコマンドで剥奪されても、アクセス権を持たないそのユーザがクエリキャッシュを通じてテーブルにアクセスすることが可能でした。 + + + + + + ユーザAのクエリキャッシュがテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、アクセス権を持たないBがクエリキャッシュを通じてアクセスすることが可能でした。 + + + + + + ユーザAのクエリキャッシュが行セキュリティが有効なテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、本来Bが見えない行をクエリキャッシュを通じて取り出すことが可能でした。 + + + + + Pgpool-II 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22以降へのアップグレードを強くお勧めします。 + それができない場合は、クエリキャッシュ機能を無効にしてください。 + + + なお、この脆弱性を修正するために、いくつかのコマンド(ALTER DATABASE, ALTER ROLE, ALTER TABLE, REVOKE)を実行すると、クエリキャッシュのすべてのデータを削除するようになりました。 + これにより、クエリキャッシュの性能に影響があるかも知れません。 + + + + + 変更点 + + + + + notice_per_node_statementをバックポートしました。 (Tatsuo Ishii) + + + これは主にテストのためです。v4.1までバックポートしました。 + + + Discussion: [pgpool-hackers: 4504] + + + + + + + 不具合修正 + + + + + + レプリケーションモードとスナップショットアイソレーションモードで発生する複数の不具合を修正しました。(Tatsuo Ishii) + + + 次の不具合を修正しました。 + + + + + レプリケーションモードおよびスナップショットアイソレーションモードでコマンドを実行すると、Pgpool-IIはクエリ準備完了メッセージを待ちますが、一部のコマンド（SET ROLEなど）がパラメータステータスメッセージを生成することを忘れていました。 + その結果、Pgpool-IIはクエリ準備完了メッセージの前に他のメッセージが到着したことをエラーとして出力していました。 + + + + + + 前のクエリがパラメータステータスメッセージを生成した場合、後続のparse()はそれを読み取って処理する必要があります。 + これは、パラメータステータスメッセージの後に続くはずのクエリ準備完了メッセージを読み取る必要があるためです。 + + + ただし、ParameterStatus()が呼び出されると、クエリ進行中フラグが設定され、このparse()呼び出しで処理されるクエリが負荷分散されている場合、バックエンドからのパラメータステータスメッセージの1つだけが処理される可能性がありました。 + パラメータステータスメッセージはSETコマンドによって生成され、SETコマンドはレプリケーションモードおよびスナップショットアイソレーションモードのすべての生きているバックエンドに送信されるため、すべての生きているバックエンドから送信される可能性がありました。 + そのため、ParameterStatus()を呼び出す前に、クエリ進行中フラグを設定解除するように修正しました。 + + + + + + + + + リリース 4.1.21 diff --git a/doc.ja/src/sgml/release-4.2.sgml b/doc.ja/src/sgml/release-4.2.sgml index 00a3d5abd..df8f377d0 100644 --- a/doc.ja/src/sgml/release-4.2.sgml +++ b/doc.ja/src/sgml/release-4.2.sgml @@ -1,6 +1,115 @@ + + リリース 4.2.19 + + リリース日 + 2024-09-09 + + + + 概要 + + このリリースには、セキュリティ修正が含まれています。 + + + クエリキャッシュ機能（）が有効な時に、データベースユーザがクエリキャッシュ経由で本来読み出せない行を読むことが可能でした。(CVE-2024-45624) + + + 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22より古く、クエリキャッシュ機能を持つすべてのバージョン(クエリキャッシュ機能は3.2で実装されました)がこの脆弱性の影響を受けます。 + + + + + + あるユーザのクエリキャッシュがテーブルに対して作成されていると、そのテーブルへのアクセス権がREVOKEコマンドで剥奪されても、アクセス権を持たないそのユーザがクエリキャッシュを通じてテーブルにアクセスすることが可能でした。 + + + + + + ユーザAのクエリキャッシュがテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、アクセス権を持たないBがクエリキャッシュを通じてアクセスすることが可能でした。 + + + + + + ユーザAのクエリキャッシュが行セキュリティが有効なテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、本来Bが見えない行をクエリキャッシュを通じて取り出すことが可能でした。 + + + + + Pgpool-II 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22以降へのアップグレードを強くお勧めします。 + それができない場合は、クエリキャッシュ機能を無効にしてください。 + + + なお、この脆弱性を修正するために、いくつかのコマンド(ALTER DATABASE, ALTER ROLE, ALTER TABLE, REVOKE)を実行すると、クエリキャッシュのすべてのデータを削除するようになりました。 + これにより、クエリキャッシュの性能に影響があるかも知れません。 + + + + + 変更点 + + + + + notice_per_node_statementをバックポートしました。 (Tatsuo Ishii) + + + これは主にテストのためです。v4.1までバックポートしました。 + + + Discussion: [pgpool-hackers: 4504] + + + + + + + 不具合修正 + + + + + + レプリケーションモードとスナップショットアイソレーションモードで発生する複数の不具合を修正しました。(Tatsuo Ishii) + + + 次の不具合を修正しました。 + + + + + レプリケーションモードおよびスナップショットアイソレーションモードでコマンドを実行すると、Pgpool-IIはクエリ準備完了メッセージを待ちますが、一部のコマンド（SET ROLEなど）がパラメータステータスメッセージを生成することを忘れていました。 + その結果、Pgpool-IIはクエリ準備完了メッセージの前に他のメッセージが到着したことをエラーとして出力していました。 + + + + + + 前のクエリがパラメータステータスメッセージを生成した場合、後続のparse()はそれを読み取って処理する必要があります。 + これは、パラメータステータスメッセージの後に続くはずのクエリ準備完了メッセージを読み取る必要があるためです。 + + + ただし、ParameterStatus()が呼び出されると、クエリ進行中フラグが設定され、このparse()呼び出しで処理されるクエリが負荷分散されている場合、バックエンドからのパラメータステータスメッセージの1つだけが処理される可能性がありました。 + パラメータステータスメッセージはSETコマンドによって生成され、SETコマンドはレプリケーションモードおよびスナップショットアイソレーションモードのすべての生きているバックエンドに送信されるため、すべての生きているバックエンドから送信される可能性がありました。 + そのため、ParameterStatus()を呼び出す前に、クエリ進行中フラグを設定解除するように修正しました。 + + + + + + + + + リリース 4.2.18 diff --git a/doc.ja/src/sgml/release-4.3.sgml b/doc.ja/src/sgml/release-4.3.sgml index 605fd0d56..45ef459e1 100644 --- a/doc.ja/src/sgml/release-4.3.sgml +++ b/doc.ja/src/sgml/release-4.3.sgml @@ -1,6 +1,115 @@ + + リリース 4.3.12 + + リリース日 + 2024-09-09 + + + + 概要 + + このリリースには、セキュリティ修正が含まれています。 + + + クエリキャッシュ機能（）が有効な時に、データベースユーザがクエリキャッシュ経由で本来読み出せない行を読むことが可能でした。(CVE-2024-45624) + + + 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22より古く、クエリキャッシュ機能を持つすべてのバージョン(クエリキャッシュ機能は3.2で実装されました)がこの脆弱性の影響を受けます。 + + + + + + あるユーザのクエリキャッシュがテーブルに対して作成されていると、そのテーブルへのアクセス権がREVOKEコマンドで剥奪されても、アクセス権を持たないそのユーザがクエリキャッシュを通じてテーブルにアクセスすることが可能でした。 + + + + + + ユーザAのクエリキャッシュがテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、アクセス権を持たないBがクエリキャッシュを通じてアクセスすることが可能でした。 + + + + + + ユーザAのクエリキャッシュが行セキュリティが有効なテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、本来Bが見えない行をクエリキャッシュを通じて取り出すことが可能でした。 + + + + + Pgpool-II 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22以降へのアップグレードを強くお勧めします。 + それができない場合は、クエリキャッシュ機能を無効にしてください。 + + + なお、この脆弱性を修正するために、いくつかのコマンド(ALTER DATABASE, ALTER ROLE, ALTER TABLE, REVOKE)を実行すると、クエリキャッシュのすべてのデータを削除するようになりました。 + これにより、クエリキャッシュの性能に影響があるかも知れません。 + + + + + 変更点 + + + + + notice_per_node_statementをバックポートしました。 (Tatsuo Ishii) + + + これは主にテストのためです。v4.1までバックポートしました。 + + + Discussion: [pgpool-hackers: 4504] + + + + + + + 不具合修正 + + + + + + レプリケーションモードとスナップショットアイソレーションモードで発生する複数の不具合を修正しました。(Tatsuo Ishii) + + + 次の不具合を修正しました。 + + + + + レプリケーションモードおよびスナップショットアイソレーションモードでコマンドを実行すると、Pgpool-IIはクエリ準備完了メッセージを待ちますが、一部のコマンド（SET ROLEなど）がパラメータステータスメッセージを生成することを忘れていました。 + その結果、Pgpool-IIはクエリ準備完了メッセージの前に他のメッセージが到着したことをエラーとして出力していました。 + + + + + + 前のクエリがパラメータステータスメッセージを生成した場合、後続のparse()はそれを読み取って処理する必要があります。 + これは、パラメータステータスメッセージの後に続くはずのクエリ準備完了メッセージを読み取る必要があるためです。 + + + ただし、ParameterStatus()が呼び出されると、クエリ進行中フラグが設定され、このparse()呼び出しで処理されるクエリが負荷分散されている場合、バックエンドからのパラメータステータスメッセージの1つだけが処理される可能性がありました。 + パラメータステータスメッセージはSETコマンドによって生成され、SETコマンドはレプリケーションモードおよびスナップショットアイソレーションモードのすべての生きているバックエンドに送信されるため、すべての生きているバックエンドから送信される可能性がありました。 + そのため、ParameterStatus()を呼び出す前に、クエリ進行中フラグを設定解除するように修正しました。 + + + + + + + + + リリース 4.3.11 diff --git a/doc.ja/src/sgml/release-4.4.sgml b/doc.ja/src/sgml/release-4.4.sgml index 9802ced46..5ae541872 100644 --- a/doc.ja/src/sgml/release-4.4.sgml +++ b/doc.ja/src/sgml/release-4.4.sgml @@ -1,6 +1,115 @@ + + リリース 4.4.9 + + リリース日 + 2024-09-09 + + + + 概要 + + このリリースには、セキュリティ修正が含まれています。 + + + クエリキャッシュ機能（）が有効な時に、データベースユーザがクエリキャッシュ経由で本来読み出せない行を読むことが可能でした。(CVE-2024-45624) + + + 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22より古く、クエリキャッシュ機能を持つすべてのバージョン(クエリキャッシュ機能は3.2で実装されました)がこの脆弱性の影響を受けます。 + + + + + + あるユーザのクエリキャッシュがテーブルに対して作成されていると、そのテーブルへのアクセス権がREVOKEコマンドで剥奪されても、アクセス権を持たないそのユーザがクエリキャッシュを通じてテーブルにアクセスすることが可能でした。 + + + + + + ユーザAのクエリキャッシュがテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、アクセス権を持たないBがクエリキャッシュを通じてアクセスすることが可能でした。 + + + + + + ユーザAのクエリキャッシュが行セキュリティが有効なテーブルに対して作成されていて、同じセッション内でSET ROLEあるいはSET SESSION_AUTHORIZATIONで他のユーザBに切り替えてそのテーブルにアクセスすると、本来Bが見えない行をクエリキャッシュを通じて取り出すことが可能でした。 + + + + + Pgpool-II 4.5.4, 4.4.9, 4.3.12, 4.2.19, 4.1.22以降へのアップグレードを強くお勧めします。 + それができない場合は、クエリキャッシュ機能を無効にしてください。 + + + なお、この脆弱性を修正するために、いくつかのコマンド(ALTER DATABASE, ALTER ROLE, ALTER TABLE, REVOKE)を実行すると、クエリキャッシュのすべてのデータを削除するようになりました。 + これにより、クエリキャッシュの性能に影響があるかも知れません。 + + + + + 変更点 + + + + + notice_per_node_statementをバックポートしました。 (Tatsuo Ishii) + + + これは主にテストのためです。v4.1までバックポートしました。 + + + Discussion: [pgpool-hackers: 4504] + + + + + + + 不具合修正 + + + + + + レプリケーションモードとスナップショットアイソレーションモードで発生する複数の不具合を修正しました。(Tatsuo Ishii) + + + 次の不具合を修正しました。 + + + + + レプリケーションモードおよびスナップショットアイソレーションモードでコマンドを実行すると、Pgpool-IIはクエリ準備完了メッセージを待ちますが、一部のコマンド（SET ROLEなど）がパラメータステータスメッセージを生成することを忘れていました。 + その結果、Pgpool-IIはクエリ準備完了メッセージの前に他のメッセージが到着したことをエラーとして出力していました。 + + + + + + 前のクエリがパラメータステータスメッセージを生成した場合、後続のparse()はそれを読み取って処理する必要があります。 + これは、パラメータステータスメッセージの後に続くはずのクエリ準備完了メッセージを読み取る必要があるためです。 + + + ただし、ParameterStatus()が呼び出されると、クエリ進行中フラグが設定され、このparse()呼び出しで処理されるクエリが負荷分散されている場合、バックエンドからのパラメータステータスメッセージの1つだけが処理される可能性がありました。 + パラメータステータスメッセージはSETコマンドによって生成され、SETコマンドはレプリケーションモードおよびスナップショットアイソレーションモードのすべての生きているバックエンドに送信されるため、すべての生きているバックエンドから送信される可能性がありました。 + そのため、ParameterStatus()を呼び出す前に、クエリ進行中フラグを設定解除するように修正しました。 + + + + + + + + + リリース 4.4.8 diff --git a/doc/src/sgml/release-4.1.sgml b/doc/src/sgml/release-4.1.sgml index 55cb1c1fc..9bec0bc02 100644 --- a/doc/src/sgml/release-4.1.sgml +++ b/doc/src/sgml/release-4.1.sgml @@ -1,6 +1,149 @@ + + Release 4.1.22 + + Release Date + 2024-09-09 + + + + Overview + + This release contains a security fix. + + + When the query cache () 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. + + + + + Changes + + + + + Back port notice_per_node_statement. (Tatsuo Ishii) + + + This is mainly for testing. Backpatch-through: v4.1 + + + Discussion: [pgpool-hackers: 4504] + + + + + + + Bug fixes + + + + + + 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(). + + + + + + + + + Release 4.1.21 diff --git a/doc/src/sgml/release-4.2.sgml b/doc/src/sgml/release-4.2.sgml index aa978656c..50cc355b8 100644 --- a/doc/src/sgml/release-4.2.sgml +++ b/doc/src/sgml/release-4.2.sgml @@ -1,6 +1,149 @@ + + Release 4.2.19 + + Release Date + 2024-09-09 + + + + Overview + + This release contains a security fix. + + + When the query cache () 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. + + + + + Changes + + + + + Back port notice_per_node_statement. (Tatsuo Ishii) + + + This is mainly for testing. Backpatch-through: v4.1 + + + Discussion: [pgpool-hackers: 4504] + + + + + + + Bug fixes + + + + + + 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(). + + + + + + + + + Release 4.2.18 diff --git a/doc/src/sgml/release-4.3.sgml b/doc/src/sgml/release-4.3.sgml index fa589c3c8..f101bc130 100644 --- a/doc/src/sgml/release-4.3.sgml +++ b/doc/src/sgml/release-4.3.sgml @@ -1,6 +1,149 @@ + + Release 4.3.12 + + Release Date + 2024-09-09 + + + + Overview + + This release contains a security fix. + + + When the query cache () 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. + + + + + Changes + + + + + Back port notice_per_node_statement. (Tatsuo Ishii) + + + This is mainly for testing. Backpatch-through: v4.1 + + + Discussion: [pgpool-hackers: 4504] + + + + + + + Bug fixes + + + + + + 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(). + + + + + + + + + Release 4.3.11 diff --git a/doc/src/sgml/release-4.4.sgml b/doc/src/sgml/release-4.4.sgml index 1fe0cfd18..2dd592017 100644 --- a/doc/src/sgml/release-4.4.sgml +++ b/doc/src/sgml/release-4.4.sgml @@ -1,6 +1,149 @@ + + Release 4.4.9 + + Release Date + 2024-09-09 + + + + Overview + + This release contains a security fix. + + + When the query cache () 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. + + + + + Changes + + + + + Back port notice_per_node_statement. (Tatsuo Ishii) + + + This is mainly for testing. Backpatch-through: v4.1 + + + Discussion: [pgpool-hackers: 4504] + + + + + + + Bug fixes + + + + + + 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(). + + + + + + + + + Release 4.4.8 -- 2.39.5