問題

Nixは設計哲学上、Nix言語(純粋関数型評価言語)とNix store(コンテンツアドレスベースのストレージ)が別個のレイヤーとして分離されている。しかし現実には、Nix言語がstoreに対して特権的地位を持っており、この両者の間に明示的なインターフェース境界が存在しない。

特権的地位の具体的様相

• 唯一の公式エントリーポイント: derivationを生成しstoreに登録する事実上唯一の経路がNix言語評価器である。nix build、nix developなどのCLIツールも内部的にNix評価器を呼び出す。
• エコシステム依存: nixpkgs全体がNix言語で記述されており、flakeシステムもNix評価器を前提とする。代替言語は常に二等市民である。
• 純粋性への信頼依存: storeの整合性がNix言語の純粋性(副作用なし、string contextを通じた依存関係追跡など)に依存している。これは言語実装の正確性を信じなければならない脆弱な信頼モデルである。

既存の回避試みの限界

• Guix: Nix言語の代わりにGuileをフロントエンドとして使用するが、nixpkgsを再利用できず、エコシステムをゼロから再構築しなければならなかった。
• Tvix: storeを異なる方法で実装しようとしたが、結局Nix言語の互換評価器を作ることに相当なコストを払っている。
• Recursive Nix: ビルド時点で他の言語からNix daemonを呼び出すことができるが、最上位のエントリーポイントは依然としてNix言語が握っている。脱出口はできたが、その扉を開く鍵はNix言語にある。

提案：すべての言語をSandboxの中へ

核心アイデア: Nix言語評価器を含むすべてのフロントエンド言語を、Nix sandboxの中でマウントされたNix daemonソケットを通じてのみstoreと相互作用するようにする。

構造変更

[現在]
Nix言語評価器 ──(特権的アクセス)──▶ Nix Store

[提案]
┌─── Sandbox ────────────────────┐
│  Nix言語評価器                  │
│  Guile / Python / Rust / ...   │──(daemonソケット)──▶ Nix Daemon ──▶ Nix Store
│  (ネットワークなし、FS分離)      │
└────────────────────────────────┘

動作方式

1. フロントエンド言語(Nixを含む)はsandboxの中で実行される。ネットワークアクセス不可、ファイルシステム分離。
2. Store関連のすべての動作(derivation登録、store pathの照会、ビルド要求など)は、sandboxの中にマウントされたNix daemonソケットを通じてのみ実行する。
3. Daemonがstoreの整合性を保証する唯一の主体となる。

利点

1. 信頼モデルの簡素化

言語の純粋性を信頼する必要がない。Sandboxがカーネルレベルで分離を強制するため、どの言語がsandboxの中で何をしようとも、storeの整合性はdaemonが保証する。言語意味論に依存する信頼よりも、OSレベルの分離に依存する信頼の方がはるかに堅牢である。

2. 言語間での対等な地位

Nix、Guile、Python、Rustなど、どの言語であってもsandboxの中でdaemonソケットプロトコルを使用することは同じである。nixpkgsがNixで記述されているということは、エコシステムの歴史的選択に過ぎず、アーキテクチャが強制するものではなくなる。

3. 既存の特殊ケースの一般化

• IFD(Import From Derivation): 評価中にビルドをトリガーする特殊ケースではなく、sandboxの中でdaemonにビルドを要求する一般的な動作となる。
• Recursive Nix: 別途の機能ではなく当然のパターンとなる。
• 評価とビルドの境界が曖昧になっても、sandboxが分離を保証するため問題にならない。

要約

現在のNixアーキテクチャにおいて言語レベルの純粋性が担っているセキュリティ役割を、OSレベルの分離(sandbox + daemonプロトコル)に下ろそうというのが、この提案の核心である。これを通じてNix言語の特権的地位が除去され、すべてのフロントエンド言語が対等な条件でNix storeを活用できるようになる。