このリリースは 9.6.7 からの修正リリース(2018/3/1リリース)です。
9.6.x からのアップデートではダンプ、リストアは不要です。
しかしながら、下記 1 番、2 番の項目を確認して、必要に応じて対応を行うことを推奨します。
また、9.6.7 より前のバージョンからアップデートを行う場合は 9.6.7 に関する技術情報を参照してください。
PostgreSQL 9.6.7 から 9.6.8 への変更点
10.3、9.6.8、9.5.12、9.4.17、9.3.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。
- 他ユーザからの search_path を使った「トロイの木馬」攻撃を防御する PostgreSQL とアプリケーションの設定方法がドキュメントに記載されました。 (Noah Misch) (10)(9.6)(9.5)(9.4)(9.3)
- pg_dump や他のクライアントプログラムで安全でない search_path 設定の使用が回避されました。 (Noah Misch, Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)
- ロジカルレプリケーションで伝播不可能なリレーションに対して伝播しようとするのを防ぐようになりました。 (Peter Eisentraut) (10)
- サブプラン内の CTE 参照で同時更新再チェック動作の間違いが修正されました。 (Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)
- 外部結合でマージ結合句が重複した場合にプランナが失敗する問題が修正されました。 (Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)
- pg_upgrade でマテリアライズドビューのための relfrozenxid の保存に失敗する問題が修正されました。 (Tom Lane, Andres Freund) (10)(9.6)(9.5)(9.4)(9.3)
- pg_dump の出力の誤りが修正されました。 (Alexey Bashtanov) (10)
- pg_dump の STATISTICS オブジェクトに対する扱いが修正されました。 (Tom Lane) (10)
- エラーコンテキストスタックで間違った PL/Python の関数名が報告されていた問題が修正されました。 (Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)
- contrib/auto_explain の log_min_duration の最大値が約 35 分から、およそ 24 日間までに引き伸ばされました。 (Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)
- 拡張モジュールを Windows に容易に移植できるようにするために、関連する GUC 変数が PGDLLIMPORT としてマークされました。 (Metin Doslu) (10)(9.6)
害意あるユーザから書き込み可能なスキーマを含む search_path 設定を使うことは、そのユーザが問い合わせの制御を取ること、そして、攻撃されたユーザの権限で任意の SQL コードを実行することをきわめて容易に可能にします。
そのため、search_path に信用できないスキーマを含めないようにすることが推奨されます。ドキュメントのスキーマ、libpq、拡張および CREATE FUNCTION の各ページについて記載を改定しました。
特に public スキーマはデフォルトで存在し、デフォルトで search_path に含まれており、全てのユーザでスキーマ上でオブジェクト作成が可能となっています。同じデータベースにアクセスする信用できない（本来制限されている）ユーザがいて、それでいて public スキーマと search_path 設定がデフォルト状態のままである場合には明らかに本脆弱性に該当します。(CVE-2018-1058)
pg_dump、pg_upgrade、vacuumdb、およびその他各種の PostgreSQLで提供されるクライアントプログラム自体に前項で記載した類のハイジャックに対する脆弱性がありました。これらプログラムはたいてい管理者ユーザで実行されるので狙われやすいターゲットです。これらを安全にするため、動作時の search_path 設定に pg_catalog スキーマだけ含まれるようになりました。また、autovacuum worker も同様に動作するようになりました。なお、pgbench と psql は本修正の対象外です。
これは非互換箇所のある修正です。これらのプログラムから間接的に実行されるユーザ定義関数（例えばインデックス式の関数）が search_path 設定に依存して記述されている（例えば public スキーマ下の関数をスキーマ修飾無しに参照している）場合、エラーが生じるようになります。(CVE-2018-1058)
FOR ALL TABLES と指定されたパブリケーションが誤ってマテリアライズドビューや information_schema テーブルの変更を伝播していました。これらは変更ストリームから無視されるべきものです。
CTE（WITH 句参照）が InitPlan や SubPlan で使われていて、問い合わせが同時更新された行に更新やロックをするために再チェックを必要とする場合に、誤った結果が返ることがありました。
コードの誤りにより稀なケースで「ERROR: left and right pathkeys do not match in mergejoin」や「ERROR: outer pathkeys do not match mergeclauses planner」といったエラーが生じていました。
（10.2 でのエラーが発生する SQL を実行） test=# EXPLAIN (COSTS off) SELECT * FROM j1 FULL OUTER JOIN (SELECT * FROM j2 ORDER BY j2.id DESC, j2.num asc) j2 ON j1.id = j2.id AND j1.id = j2.num; ERROR: left and right pathkeys do not match in mergejoin （10.3 での応答） QUERY PLAN ------------------------------------------------------ Merge Full Join Merge Cond: ((j2.id = j1.id) AND (j2.num = j1.id)) -> Sort Sort Key: j2.id DESC, j2.num -> Seq Scan on j2 -> Sort Sort Key: j1.id DESC -> Seq Scan on j1 (8 rows)
アップグレード後にマテリアライズドビューのデータが破損する可能性がありました。「ERROR: could not access status of transaction ...」や「ERROR: found xmin ... from before relfrozenxid ...」というエラーが現れます。
この問題は、めったに更新されない、もしくは REFRESH MATERIALIZED VIEW CONCURRENTLY のみで更新をしていたマテリアライズドビューで発生しやすいものと見られます。
シーケンスの MAXVALUE や MINVALUE がデフォルト値であるなら、ダンプ出力で省略しますが、その判断が間違っていました。
大きな値を指定した場合に以下のような誤動作が報告されました。
（誤動作例） db=# CREATE SEQUENCE foo INCREMENT BY -1 MINVALUE -9223372036854775808 MAXVALUE 9223372036854775807; db=# q $ pg_dump db : 中略 CREATE SEQUENCE foo START WITH 9223372036854775807 INCREMENT BY -1 NO MINVALUE NO MAXVALUE CACHE 1; : 後略
拡張統計のオブジェクトが正しいスキーマにリストアされなかったり所有者が正しくない状態になる可能性がありました。
以下のように入れ子で PL/Python を呼び出している場合において該当します。
(障害がおきる例)
db=# CREATE FUNCTION notice_innerfunc() RETURNS int AS $$
plpy.execute("DO LANGUAGE plpythonu $x$ plpy.notice('inside DO') $x$")
return 1
$$ LANGUAGE plpythonu;
db=# CREATE FUNCTION notice_outerfunc() RETURNS int AS $$
plpy.execute("SELECT notice_innerfunc()")
return 1
$$ LANGUAGE plpythonu;
また、入れ子になった PL/Python の DO ブロックは一部のプラットフォームで NULL ポインタ参照によるクラッシュをひき起こす可能性がありました。