GrooveSeek

Semantic search over a Markdown knowledge base, served over MCP.

View the Project on GitHub alphabet-h/grooveseek

16. plugin の置き場は知識ベースの外に置く

背景と課題

ADR-0013 は grammar plugin を 「読み込むこと自体が実行である」と定義し、そこから「plugin の置き場は特権的な設定に なる」を帰結として導いた。実装はその帰結を守っている — ただし「誰がその値を書けるか」 についてだけである。知識ベースの隣で見つかった設定ファイルが grammar_dir を書いていても 安全な既定へ差し戻し (R4)、v1.3.0 では 1 段上流の [parsers].enabled にも同じ規則を 広げた (R5)。

守られていなかったのは「その値が何を指せるか」である。grammar_dir は知識ベースの 内側を指せる。検査も警告も無い。

一方、知識ベースディレクトリは ADR-0003 以来一貫して 「セキュリティ境界ではない」と宣言されている。crate::links の module doc も README も 同じことを書く。索引される内容を決めるのは知識ベースに書ける者であり、それは設計上 そういうものだ、という宣言である。

2 つが交わる地点に検査が無い。置き場が知識ベースの内側にあると、知識ベースに書ける者は そこにライブラリを置くだけで groove のプロセスで任意のコードを実行できる。 「このフォルダを index して」が「このコードを実行して」に化ける唯一の地点である。

判断の軸

検討した選択肢

  1. 警告だけ出して読み込む
  2. 安全な既定へ差し替えて警告する (信頼できない設定に対する R4 と同じ形)
  3. エラーで止める

決定

選択肢 3 を採る。解決後の grammar_dir が kb_path の内側 (等しい場合を含む) なら、 設定の信頼度に関わらず実行を止める。

選択肢 1 を採らないのは、警告が主張だけになるからである。ここで要るのは「読み込む前に 止めること」であって「読み込んだ後に説明すること」ではない。ADR-0003 が 「ガードは実力以上のことを主張してはならない」と書いたのと同じ問題が、向きを変えて現れる。

選択肢 2 を採らないのは、差し替えの根拠が信頼できる設定には無いからである。R4 が 信頼できない設定の値を黙って捨ててよいのは、その値を書いた者に権限が無いからだ。 運用者自身が書いた値を黙って別の場所へ向けると、運用者は自分が置いた plugin が読まれない 理由を知る手段を持たない。

判定は grammar_dir が解決された後に行う。環境変数・設定ファイル・OS 既定のどれで 決まっても危険は同じなので、入力ごとに分けない — 分ければ同じ物理状況が複数の意味を持つ。

拒否はどの入力を直せばよいかを名指す。環境変数を設定した利用者に「設定ファイルを直せ」と 案内するのは、従っても直らない指示になる (環境変数が優先されるため)。

結果と代償

参考