処理へ大きなサービスインターフェースを渡さず、必要な操作だけを関数として渡すと、その依存関係は最小権限に近づく。 顧客へのメール送信処理にデータベース全体を渡す代わりに、特定顧客を一度だけ読み取れる関数を渡せば、別の顧客を読む誤りや書き込みの誤りを局所的に防げる。
sendEmail(readCustomer42Once)しかし、関数を引数として渡す形だけでは、最小権限を保証しない。 メール送信処理が大域変数、サービスロケーター、静的メソッド、ファイルシステム、ネットワークから別の権限を取得できるなら、渡した関数は利用可能な権限の一部にすぎない。
ケイパビリティ方式として保証するには、外界へ作用する権限を偽造不能な参照からしか取得できない実行環境が必要になる。 既存の二つの対象の間に新しい権限関係を作れるのは、両方への参照を持つ別の対象が参照を委譲した場合だけに制限する。 無条件に呼べる変更可能な大域機能は、この制限を迂回する大域的権限になる。
したがって、一メソッドのインターフェースや関数単位の依存性注入は、意図を明確にして偶発的な誤用を減らす設計技法としては役立つ。 それを保安上の保証として扱えるかは、渡されていない権限へ到達する別経路を言語、実行環境、静的検査のどれが遮断するかで決まる。
これは副作用の型付けが何を追跡するかにも通じる。 型に現れたケイパビリティだけを見ても、追跡されない大域的な操作が残れば、関数が起こせる効果の全体は分からない。
https://speakerdeck.com/swlaschin/designing-with-capabilities
https://www.erights.org/elang/kernel/auditors/index.html
https://www.erights.org/elib/capability/ode/ode-capabilities.html
#capability #security #dependency-injection #least-authority #effect-system