* KH-FDPLのノート0004
-(by [[K]], 2015.03.17)
** (1) セキュリティ
-KH-FDPLはセキュリティに配慮しています。
-たとえば、配列の添え字に巨大な数字を指定しても攻撃にはなりません。KH-FDPLの配列はa[0]とa[1億]に代入したとしても、それは「0というキーに対する値」「1億というキーに対する値」を記憶するだけで、それらがメモリ上で連続に入るわけではないので、問題にはならないのです。・・・これはプログラミング初心者が配列の添え字の上限で悩んでほしくないということで考えた仕様でもありますし、配列の宣言をしないで使うためにどうしたらいいのかを考えてもこの仕様になります。
-プログラムにあるオブジェクトを渡すと、そのオブジェクトに対しては自由に読めてしまいますが、他のオブジェクトには手出しができません。書き込みや削除ができるかどうかについては、オブジェクトを渡したときに書き込み権限があるかどうかで決まります。書き込み権限がない状態で渡した場合は、読み込みしかできません。また一般的なファイルシステムとは異なり、子から親にたどっていくことはできません。ですからその手の攻撃もできません。
-ポインタなどでは、もしポインタの指している先のオブジェクトが開放されていたら、つまり不正なポインタを使ってアクセスしようとしたら、必ず検出して止まります。

** (2) デバッグ支援
-KH-FDPLでは、セキュリティとデバッグ支援を明確には区別しません。というのはセキュリティホールはバグの一種だと考えているからです。デバッグ支援を充実させれば、自然にプログラマはプログラムを作りやすくなり、意図しない動作をすることは減り、セキュリティホールも減ると思います。

-書き込み禁止のオブジェクトに対して書き込みをしたらどうすべきでしょうか。方法は2つあると思います。
--(a) 書き込みを無視して続行する。
--(b) エラーとして報告する。
-私は基本的には(b)を推します。なぜなら不正な動作を勝手にNOP化して続行するのは、プログラマの盲点を増やすことになると思うからです。セキュリティやデバッグ支援のあるべき姿としては、「もしその防御機構がなかった場合に不正動作が起きてしまうものはまずい」ということです。KH-FDPLはそんなプログラムの撲滅の手助けをするべきであって、ダメなプログラムでもなんとなく動いてしまうことを目指すべきではありません。
--しかし、人間があえてそういう「まずい場合でもできるだけ回避してくれる仕様」を望むのであれば、そういう仕様もあっていいとも思いますし、KH-FDPLはそういう仕様も受け入れられるようになっているべきだと思います。

** (3) 万能性
-セキュリティのために、あれこれとできないことがある一方で、でも「やろうと思えば何でもできる」もとても重要だと思います。特に初心者にはこれは必要だと思います。
-セキュリティのために、あれこれとできないことがある一方で、でも「やろうと思えば何でもできる」もとても重要だと思います。特に初心者にはこれは必要だと思います。あれもできません、これもできません、というのはストレスがたまるし、理解の助けにもなりません。
-たとえば、オブジェクトに対するアクセス権については、ユーザが指定してプログラムに渡しさえすれば、ルートでも何でもアクセスできます。

* こめんと欄

#comment
トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS