【何が起きたか】Ubuntu 26.10で基本コマンド群がRust実装へ完全移行
CanonicalはUbuntu 26.10において、OSの基本コマンド群である「coreutils」のデフォルト実装をRust言語製へ完全に切り替えました[1]。coreutilsとは、ファイル操作やテキスト処理を行うLinuxの最も基本的なツール群のことです[1]。このパッケージには、catやls、chmodなど、システムで日常的に使われる100以上の標準コマンドが含まれています[1]。
今回の置き換えは、各コマンドの実行名や基本的な用途を変更するものではありません[2]。GNUプロジェクトがC言語で開発してきた従来の実装を、オープンソースの「uutils」プロジェクトによるRust実装へ差し替えています[2]。uutilsは設定変更なしでそのまま使える「ドロップイン置換」を目指しており、GNU版との振る舞いの差はバグとして扱われます[2]。
Ubuntu 26.10では、直前の長期サポート版であるUbuntu 26.04 LTSで互換性問題から保留されていた「cp」「mv」「rm」の3コマンドが新たに置き換わりました[3]。ファイルの複製や移動、削除という重要操作を担う3つのコマンドが移行したことで、標準coreutils全体のRust化が完了しました[4, 5, 6, 7]。
後輩コマンド名や基本的な使い方は今までと全く変わらないのですね。
先輩その通りだね。日常的なシェル操作の手順を変えずに、内部の実装を安全なものへ差し替えるのが今回の狙いだよ。
後輩外側からは同じに見えても、中身のプログラム言語がC言語からRustへ根本的に入れ替わっているわけですね。
先輩まさにそこがポイントだね。互換性を保ちながら、システム基盤の安全性を底上げする試みなんだよ。
【なぜそうしたのか】速度ではなく「メモリ安全性」と「堅牢性」を重視した背景
Canonicalがcoreutilsの移行を進めた最大の狙いは、処理速度の向上ではありません[8]。Canonicalは、Rust言語によって実現しやすい安全性とシステムのレジリエンス(障害や攻撃に対する堅牢性)を高めることを主目的に挙げています[8]。Rustの型システムや「借用チェッカー(メモリ参照の安全性を厳格に検査する仕組み)」を活用し、基盤ツールのセキュリティ保証を高める方針です[9]。
Rust化によって最も直接的な低減が期待されるのは、C言語実装に特有のメモリ破壊などの脆弱性です[10, 11]。uutils coreutilsは互換性を保ちつつ、メモリ安全性の確保を主要目標に掲げています[10]。プロジェクトでは低レベルなシステムコールを安全な実装へ移行し、安全性が保証されないコード領域を削って攻撃面を狭める作業を進めてきました[11]。
一方、uutilsプロジェクト自身は、移行のより広い目的を基盤ソフトウェアの「現代化」だと説明しています[12]。次世代の開発者が保守や改善に関わりやすくすることが主眼であり、セキュリティ自体を第一の目的とは位置づけていません[12]。また、同プロジェクトは多様なOSで動作するクロスプラットフォーム性も重視していますが、これもCanonicalが第一に掲げた採用理由ではありません[13]。
ただし、言語をRustに変えただけで脆弱性が自動的になくなるわけではありません[14]。uutilsが実施した外部セキュリティ監査では2ラウンドで計113件の問題が特定され、その中心はファイルシステム処理における競合状態でした[14, 15]。ファイルの存在や権限を確認した瞬間と使用する瞬間の時間差を突く「TOCTOU(検査と使用の競合)」競合などは、Rustの型システムだけでは防げない課題です[14, 16, 18]。具体的には、installコマンドにおいてファイルの削除と再作成の隙間にシンボリックリンクを差し込まれ、重要ファイルを意図せず上書きできる問題などが報告されました[17]。
後輩メモリ安全なRustで書き直せば、セキュリティの懸念はすべて解消されると考えてよいのでしょうか。
先輩残念ながらそうとは言えないんだ。メモリ破壊は防げても、ファイル操作のタイミングを突く競合のような論理的な問題は防げないよ。
後輩プログラミング言語の機能だけに頼るのではなく、OSのファイル操作をどう設計するかが問われるわけですね。
先輩その通りだね。言語の持つ安全性と、システムコールを安全に扱う設計の両方が揃って初めて堅牢な基盤になるんだよ。
【なぜ今なのか】26.04 LTSでの慎重な保留を経て整った移行条件
Canonicalは段階的な検証を経て、Ubuntu 26.10での移行完了に至りました。まずUbuntu 25.10において、長期サポート版(LTS)を見据えた実環境テストを最大化するためにrust-coreutilsを先行導入しました[19]。この段階では互換性問題に備えてGNU版も併存させ、利用者が切り戻せる手段を維持していました[20]。続くUbuntu 26.04 LTSではセキュリティ修正を取り込んだuutils 0.8.0を採用したものの、未解決のTOCTOU問題が8件残っていたcp、mv、rmの3コマンドについてはGNU版のまま据え置かれました[21, 22, 23, 24]。
26.04 LTSでの保留以降、uutilsの上流プロジェクトではファイルシステム操作に関する安全性修正が集中的に進められました[25]。対策にはRustの型検査ではなく、OSレベルの安全なファイル操作設計が導入されています[26]。具体的には、パス名ではなくファイルディスクリプタ(OSがオープン中のファイルを識別する整数値)を用いた操作への移行や、シンボリックリンクを安易に追跡しない処理の徹底です[25, 26, 28]。これにより、ディレクトリ走査中にリンクを差し替えられる危険が抑制されました[25, 28]。また、依存ライブラリの整理や安全性の管理も進展しました[27]。
こうした改修の結果、uutils 0.10.0ではGNU互換性テストの合格数が690件中645件に達し、失敗数は前バージョンの56件から27件減少して29件となりました[29, 30, 31]。Ubuntu 26.10での完全移行は、25.10での実証と26.04 LTSでの安全重視の保留を経て、上流の改修とテスト改善により採用条件が整ったためだと解釈できます[32]。
後輩26.04 LTSで見送られた3つの重要コマンドが、今回の26.10で移行できた決め手は何だったのですか。
先輩監査で指摘された競合問題に対して、ファイルディスクリプタを活用した安全な処理など地道な改修が進んだからだね。
後輩安定性が最優先されるLTSで無理に導入せず、立ち止まって品質を高めた判断が功を奏したわけですね。
先輩その通りだね。スケジュールを優先するのではなく、安全性の根拠が揃うのを待って移行を完了させたと言えるよ。
【何が変わるか】ドロップイン互換の実現度と性能・動作の差異
uutilsはGNU版のドロップイン置換を目標にしており、標準出力やエラーメッセージ、終了コードの一致方針を掲げています[33]。一般的なシェルスクリプトや管理ツールは通常の使い方であれば概ねそのまま動くと考えられますが、完全な一致には達していません[34]。例えば端末で構文解析エラーが発生した際、GNU版は1行の簡潔なエラーを出力しますが、uutils版は指摘箇所にキャレット(^記号)を表示するコンパイラ風の詳細診断を示します[35]。ただし、パイプ接続時やスクリプト実行時には互換性を考慮してGNU形式の簡潔なメッセージが維持されます[35]。また、rmの進捗表示(--progress)など独自の拡張オプションも存在します[36]。
互換性テストの状況を見ても、dateやcut、SELinux関連、sortのロケール処理などに失敗やスキップが残っています[37, 38]。uutilsの公式ドキュメント自身も、GNU版と比べて未実装のオプションや異なる挙動が残る可能性を認めています[37]。さらに一部のGNUテストは内部動作を検査するため、内部構造が異なるuutilsでは仕組み上再現できないものもあります[39]。国際化に関してもUTF-8を重視して対応を進めていますが、数値処理(LC_NUMERIC)の調整など継続的な修正が行われている段階です[40]。また、glibcの互換性要件や、古いLinuxカーネル(6.4未満)でpanicが発生した報告など、実行環境に応じた注意点も存在します[41, 42]。
性能特性にも特有の傾向があります。uutilsは全機能を1つのファイルにまとめる「マルチコールバイナリ」形式と個別バイナリ形式を選択できます[43]。uutils 0.10.0では、実際の実行プロファイルに基づき最適化を行う「PGO(プロファイルに基づく最適化)」によって最大31%の高速化が確認されました[44, 46]。一方で、マルチコール形式に起因するコマンド起動時のオーバーヘッドが存在します[44, 45]。短時間のコマンドを大量に起動する環境では、GNU版のlnコマンドがuutils版より3.14倍高速に動作した実測報告もあり、事前の測定が推奨されます[44, 45]。
| 項目 | 指標・測定条件 | 測定結果・詳細 | 出典・対象バージョン |
|---|---|---|---|
| GNU互換性テスト合格数 | 総数690件中の合格件数 | 645件合格(合格率93.48%) | uutils 0.10.0 [29] |
| GNU互換性テスト失敗数 | 総数690件中の失敗件数 | 29件失敗(前版0.9.0比で27件減少) | uutils 0.10.0 [29] |
| 最適化による処理性能 | PGO(プロファイルに基づく最適化)適用時 | 最大31%の高速化(非PGO比) | uutils 0.10.0 [44] |
| コマンド起動時間差 | 単発の短時間コマンド実行(lnの例) | GNU版が3.14±0.44倍高速(マルチコール形式の差) | Ubuntu 25.10実測報告 [44, 45] |
後輩最適化によって速くなった処理がある一方で、コマンド自体の起動時間は伸びるケースがあるのですね。
先輩そうなんだよ。スクリプトの中で軽いコマンドを何千回も繰り返し呼び出すような場面では、起動時間の差が響く可能性があるね。
後輩Rust製だからといって一律に高速化すると思い込まず、自社の処理内容に合わせて測ってみる姿勢が欠かせませんね。
先輩まさにその通りだね。処理性能と起動オーバーヘッドのトレードオフを理解した上で、実測に基づいて評価することが重要だよ。
【誰に影響するか】運用環境での注意点とGNU版への切り戻し手順
今回の移行による影響は、システムの運用形態によって異なります。Ubuntu Desktopで通常のファイル操作やシェル操作を行う場合、コマンド名が変わることはなく通常通り利用できます[47]。一方でUbuntu Serverを運用する管理者は、root権限で再帰的なファイル操作を行う際に注意が必要です[48]。cpやrm、chmod、installなどのコマンドについて、シンボリックリンクの扱いや競合対策の挙動を確認しておくことが求められます[48]。
開発環境やCI(継続的インテグレーション)、コンテナ環境でも個別の検証が必要です。標準的な使い方であれば動作する可能性が高いものの、GNU固有のオプションや終了コード、境界条件に依存している処理は不整合を起こす懸念があります[49]。特にUbuntu 26.10をベースにしたコンテナやクラウド環境では、ベースイメージを更新するだけでコマンドの実装が切り替わります[50]。そのため、ビルド処理や運用自動化スクリプトの再検証を行い、必要であればGNU版を明示的に指定する構成が妥当とされています[50, 51]。
万が一互換性の問題が発生した場合、公式の切り戻し手段が提供されています。UbuntuにおいてcoreutilsはOSの稼働に不可欠な「Essential(必須)」パッケージに指定されています[52]。そのため、空のcoreutilsパッケージから機能提供元を切り替えるproviderパッケージの構成が採用されています[52]。GNU版へ戻すには、以下のAPTコマンドを実行します[53]。
sudo apt install coreutils-from-gnu --allow-remove-essential
このコマンドでは必須パッケージを一時的に外す指定(--allow-remove-essential)が必要となるため、リモートの本番環境では慎重な作業が欠かせません[54]。作業前のスナップショット取得やコンソール接続の確保を行い、切り替え後にls --versionを実行して動作を確認する体制が推奨されます[54]。
Ubuntu 26.10での移行完了は、運用の保守負担が消滅したことを意味しません[55, 56]。uutilsの上流コミュニティは活発に活動しており、2026年8月には57人の開発者から476件のコミットが寄せられました[56]。それでもTOCTOU競合やシンボリックリンク処理、依存ライブラリの更新など、安全性を維持するための継続的な追跡とアップデートが必要とされています[55, 56]。
後輩万が一システムで非互換の問題が起きたとしても、GNU版に戻す手順が公式に用意されているのは心強いですね。
先輩そうだね。ただし必須パッケージの差し替えを伴うから、通常のアプリアップデートとは違って慎重な作業が必要だよ。
後輩本番サーバーでぶっつけ本番で実行するのではなく、事前のスナップショットや検証環境でのリハーサルが欠かせないわけですね。
先輩その通りだよ。復旧手順が整っているからこそ、リスクを把握した上で落ち着いて運用設計を進めることが大切なんだ。



