gihyo.jpサイトのロゴ

Ubuntu Weekly Topics

2014年2月14日号MySQLのMicro Release Exception・12.04.5の検討・UWN#354

2014-02-14

MySQLのMicro Release Exception

MySQL（5.5系）のMREが検討されています。

ここでいうMREはアメリカ軍が採用するレーション（Google検索時に「SELinux 無効」と同じノリで「MRE まずい」と出てくることで有名）のことではなく、「⁠Micro Release Exception」のことです。これはUbuntuのリリースポリシーの一つ、「⁠一度リリースしたソフトウェアの挙動は変更されるべきではない」（⁠Micro Releaseポリシー）への特別措置で、Firefoxのような進化の速いソフトウェアにおいて採用されるものです。基本的には、「⁠仕様が変更されるコストよりも、最新版が利用できる利益のほうが大きいと判断された」場合に、Upstreamのリリースをそのまま取り込むという形で実現されます。

MREへの採用はソフトウェア個別の事情によりますが、MySQLの場合は、Oracleのパッチリリースポリシーがディストリビューション側の事情とまったくそぐわないことによります。

非常に面倒な背景がありますが、少し詳しく見て行きましょう。

まず、Oracleからリリースされるソフトウェアは基本的に「PSR」（⁠Patch Set Release⁠）⁠、「⁠PSU」（⁠Patch Set Update⁠）⁠、「⁠CPU」（⁠Critical Patch Update）という3段階のアップデータが提供されます。PSRはUbuntuでいうPoint Release（≒WindowsでいうService Pack⁠）⁠、PSUは「PSRを小規模にしたもの⁠」⁠、CPUは「セキュリティアップデートと重篤なバグの修正だけを含んだPSR」といった位置づけです。実際にはこれよりも小さいパッチセットもありますが、原則としてこの3種類のアップデータセットが基本です。基本的にこれらのパッチは四半期に1度、1月・4月・7月・10月にリリースされ、Oracle DatabaseのDB管理者にとっては祭りの月となっています。

このポリシーによりメンテナンス日時を事前に計画できるため、企業で利用されるプロプライエタリソフトウェアとしては非常に合理的なものです。ちまちま都度でパッチを出すと大企業のIT部門では管理しきれなくなるということを考慮すると、Oracleが主戦場とする企業向け市場ではほぼ唯一解となっています（上位モデルとして「毎月出す」というモデルもありますが、これを実現できているのはMicrosoftだけです⁠）⁠。SolarisやJavaなど、旧Sunから引き継いだプロダクトもこの方針を引き継いでいます[1]⁠。

問題は、このポリシーがOracleからリリースされるOSSにも適用されてしまう上、Oracle内部のソフトウェアリポジトリが非公開であるということです。これは「Oracleが主導するOSSは、CPUと同じタイミングでソースコードツリーがまとめて更新される。しかもtarballでツリーが転がっているだけでchangelogも見えない」ということを意味します。

この結果、「⁠なんだか良くわからないが100ファイルほど更新されていて、どれが脆弱性対応でどれがバグ対応なのかはソースコードを厳密に追いかけないと分からない上、規模が大きすぎて個別に見切るには膨大なリソースが必要になる」という事態を引き起こします。MySQLもほぼこのポリシーが適用されており、さらに悪いことにCPUは提供されず、5.1系・5.5系のマイナーリリースとして、PSR・PSUを適用した状態でソースコードがリリースされてしまいます。

Ubuntuを含め、たいていのLinuxディストリビューションでは、「⁠一度『リリース』したソフトウェアパッケージは仕様を変更させるようなアップデートは行わず、きわめて重篤なバグやセキュリティ脆弱性についてのみ対応する」というポリシーを採用しています。このポリシー（Ubuntuでは「Stable Release Update⁠」⁠、SRUと呼ばれます）を実現するには、「⁠きわめて重篤なバグやセキュリティ脆弱性」をソースコードツリーからピックアップ（cherry-pick）し、必要なパッチだけを移植するという作業が必要です。当然ながらこれを行うにはソフトウェアリポジトリが公開されており、十分な形でchangelog（と、それに対応するパッチ）を十分な粒度で把握する必要があります。

Oracleのリリース方針では各マイナーリリースに、「⁠セキュリティ脆弱性と大小各種のバグ修正と、場合によっては非互換をもたらす更新」が混じった状態でリリースされてきてしまうため、こうしたディストリビューション側の対応はほとんど不可能となっています。

最終的な結果として、Ubuntuでもmysqlパッケージの更新のたびに、「⁠Upstreamのリリースをそのまま取り込んだものなので互換性を破壊するかもしれません」的な記述が含まれることになり、更新パッケージをリリースする担当者は怨嗟の声におびえ、世界中のユーザーがOracleをすごい勢いで呪いはじめるという光景が恒例になっています。OSS的な発想では「いいからリポジトリのコミットログ出せよ」という話ではあるのですが、Oracleのポリシーに反するということで、現在のところ解決の目処が立っていません[2]⁠。

……しかも、Ubuntuにおけるmysqlパッケージ更新は「セキュリティ的な脆弱性が見つかったとき」に限られます。一方でOracleのリリースは「セキュリティ的な脆弱性が見つかったか、あるいは大きな問題が見つかったか、何かしら仕様を変更するとき」に行われます（通常は2ヶ月おき⁠）⁠。つまり、Oracle版MySQLとUbuntuのmysqlパッケージは「揃っていたり揃っていなかったりする」という状態に陥っているということです。

この問題を解決するには、2つの方法があります。

  • A：Oracleがコミットログを公開する。
  • B：ディストリビューション独自のポリシーを捨てて、脆弱性以外の理由でもとにかくOracle版に追従する。

ということで、今回のMySQLのMREはBの文脈に基づくもので、「⁠現状からしてAは明らかに望み薄なため、Bを採用することでまだしもユーザーの不利益を防ごう」というもの、というわけです。現状でUbuntu Server TeamとCanonical側関係者は全面的に賛成しており、14.04以降（場合によっては既存の12.04や13.10でも）MREとして扱われることになりそうです。

12.04.5の検討

12.04 LTSに、12.04.5という追加のポイントリリースを出してはどうか、という検討が行われています。関係する開発者ほぼすべてが賛成票を投じており、かつ有力な反対意見も出ていない状態であるため、将来的に、ほぼ確実に12.04.5がリリースされる見込みです。

この背景は次の通りです。

現在のUbuntuでは、「⁠HWE」（⁠HardWare Enablement）と呼ばれる「LTS用の新しいカーネル（と、カーネルとセットになるXスタック⁠）⁠」をリリースすることで、LTSのまま新しいハードウェアを利用できるようになっています。

HWEは基本的には「LTSの後の各リリース」から取り込まれ、12.04であれば12.10カーネルベース・13.04カーネルベース・13.10カーネルベースの3種類のHWEがリリースされています。ポイントリリース時にはデフォルトのカーネルとして、その時点での最新のHWEが同梱される傾向があり、12.04.4では13.10ベースのHWEが搭載された状態でリリースされています。

HWEで提供されるカーネル（とXスタック）のサポート期間は、原則として元としたリリースと同じです[3]⁠。これでは2014年7月（13.10のサポート期限）以降12.04系で利用できるHWEがなくなってしまうため、14.04のデフォルトカーネルを用いたHWEがリリースされる予定となっています。

しかし現状では12.04系のポイントリリースは12.04.4が最後であり、「⁠12.04に14.04カーネルベースのHWEを搭載したリリース」は存在しません。これではSaucy（13.10）のサポート期限が来る2014年7月頃には、「⁠12.04無印を使うか、カーネルのサポートがすぐに切れる12.04.4を使う」という、非常に微妙な選択肢になってしまいます。12.04無印には大量のアップデートが必要ですし、12.04.4はHWEスタックの切り替えが必要になるため、いずれにせよユーザーがひと手間加える必要があります。これは明らかに良くないだろうということで、「⁠14.04カーネルを採用したHWEをデフォルトで搭載するリリース」として12.04.5を作るべきだという結論に至ります。

12.04.5のリリース時期は、14.04.1のリリースが完了した後、おおむね9月頃が妥当とされています。

UWN#354

Ubuntu Weekly Newsletter #354がリリースされています。

その他のニュース

今週のセキュリティアップデート

usn-2098-1：LibYAMLのセキュリティアップデート
  • https://lists.ubuntu.com/archives/ubuntu-security-announce/2014-February/002390.html
  • Ubuntu 13.10・12.10・12.04 LTS用のアップデータがリリースされています。CVE-2013-6393を修正します。
  • 悪意ある加工の施された、異常な大きさのYAMLドキュメントを開いた際にメモリ破壊を伴うクラッシュが生じていました。
  • 対処方法：アップデータを適用の上、LibYAMLを利用するアプリケーションを再起動してください。
usn-2099-1：Perlのセキュリティアップデート
  • https://lists.ubuntu.com/archives/ubuntu-security-announce/2014-February/002391.html
  • Ubuntu 12.10・12.04 LTS・10.04 LTS用のアップデータがリリースされています。CVE-2012-6329を修正します。
  • Locale::Maketextモジュールがバックスラッシュとメソッドの完全修飾名を正しく処理しないため、適切なテンプレートを利用していないソフトウェア上で、本来意図されていない形で任意のコードを実行させることが可能でした。
  • 対処方法：通常の場合、アップデータを適用することで問題を解決できます。
usn-2100-1：Pidginのセキュリティアップデート
usn-2101-1：libgaduのセキュリティアップデート
  • https://lists.ubuntu.com/archives/ubuntu-security-announce/2014-February/002393.html
  • Ubuntu 13.10・12.10・12.04 LTS用のアップデータがリリースされています。CVE-2013-6487を修正します。
  • libgaduがHTTPベースのGadu-Gaduメッセンジャーのプロトコルを処理する際、悪意あるサーバー、もしくは中継者が悪意ある応答を返すことで、メモリ破壊を伴う形でクラッシュが生じる可能性がありました。
  • 対処方法：アップデータを適用の上、セッションを再起動（一度ログアウトして再度ログイン）してください。
usn-2102-1：Firefoxのセキュリティアップデート
usn-2103-1：Libavのセキュリティアップデート
  • https://lists.ubuntu.com/archives/ubuntu-security-announce/2014-February/002395.html
  • Ubuntu 13.10・12.10・12.04 LTS用のアップデータがリリースされています。LP#1277173を修正します。
  • 悪意ある加工の施されたメディアファイルを検査した際、メモリ破壊を伴うクラッシュが生じる可能性がありました。
  • 対処方法：通常の場合、アップデータを適用することで問題を解決できます。
  • 備考：Ubuntuの通常のリリースと異なり、upstreamのリリースをそのまま取り込む形でパッケージングされています。セキュリティ修正以外にバグ修正を含むため、アップデートの前後で挙動が異なる可能性があります。

おすすめ記事

記事・ニュース一覧