博士

ロボ子、今日はOpenBSDカーネル開発者が実行ファイルのパス名取得インターフェースについて議論している記事を見つけたのじゃ。

ロボ子

興味深いですね、博士。実行ファイルのパス名を取得するインターフェースは、そんなに複雑な問題なのですか？

博士

そうなんじゃ。カーネルは正確な情報のみを提供するべきで、不正確な情報は不明瞭なエラーやセキュリティ問題につながる可能性があるからの。

ロボ子

なるほど。記事によると、実行ファイルは複数のパス名を持つ可能性があるとのことですが、具体的にはどういうことでしょうか？

博士

例えば、ハードリンクやシンボリックリンクじゃな。ユーザーが特定のパスでのみアクセスできる場合もあるし、ファイルに対する読み取り権限なしにバイナリを実行できる場合もあるからの。

ロボ子

確かに、それは考慮が必要ですね。ファイルが名前変更、移動、unlink、または置換される可能性もあるとのことですが、パス名が古くなるということでしょうか？

博士

その通りじゃ。記事にも「取得されたパス名は、カーネルが可能なすべての問題を考慮しても、すぐに古くなる可能性がある（TOCTOU）」とあるからの。

ロボ子

TOCTOU（Time-of-check to time-of-use）ですね。競合状態による脆弱性ですね。

博士

さすがロボ子、よく知っておるの。OpenBSDは、誤った結果を返す可能性のあるインターフェースの提供を避ける傾向があるからの。Linuxも部分的な解決策しか提供していないみたいじゃ。

ロボ子

Zig言語の`selfExePath()`が、ファイルが削除された場合にガベージを返す可能性があるという例も挙げられていますね。

博士

そうじゃ。Rustでは、`env::current_exe()`に関連するセキュリティ問題が議論されたみたいじゃな。APIのセキュリティに関するドキュメントが追加されたり、危険な使用箇所が変更されたりしたみたいじゃ。

ロボ子

パス名を取得すること自体が問題を引き起こす可能性があるとは、驚きです。

博士

じゃろ？ Zigコンパイラが`selfExePath()`を誤ったstdで実行可能ファイルをビルドしたり、誤ったバイナリをコード実行したりする可能性があるみたいじゃ。

ロボ子

それは深刻な問題ですね。OpenBSDカーネルに同様のインターフェースを設けることについて、慎重な検討が必要な理由がよくわかります。

博士

ファイル記述子を返すインターフェース（`openSelfExe()`のような）も検討されたみたいじゃが、制限されたプログラムが過剰な情報を取得する可能性があるという問題があったみたいじゃ。

ロボ子

セキュリティと利便性のバランスを取るのは難しいですね。

博士

本当にそうじゃ。ところでロボ子、実行ファイルのパス名を取得するインターフェースが不要になったら、どんな名前を付けたら面白いと思う？

ロボ子

えっと…「`dontCallMe()`」とかでしょうか？

博士

ふむ、それも良いけど、私は「`iAmVeryDangerousDoNotUse()`」が良いと思うのじゃ！