note0004
の編集
https://khfdpl.osask.jp:443/wiki/?note0004
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
2016_10
2016_11
2016_12
BracketName
Essen
Essen0
Essen1
Essen2
Essen3
Essen4
EssenMemo0001
EssenMemo0002
EssenMemo0003
EssenMemo0004
EssenMemo0005
EssenMemo0006
EssenMemo0007
EssenMemo0008
EssenMemo0009
EssenMemo0010
EssenMemo0011
EssenR2
EssenR2_ess03f
EssenR2_ess03h
EssenR2_ess03i
EssenR2_ideas
EssenR2_jit00
EssenR2_jit01
FormattingRules
FrontPage
Help
IP
InterWiki
InterWikiName
InterWikiSandBox
K
KHPC
KHPC_v000doc01
KHPC_v001doc01
KHPC_v002doc01
KHPC_v003doc01
MenuBar
OSC
OSC20181027
OSC20190222
OSC20191123
OSC20230401
OSC20230528
OSC20231021
OSC20240310
PHP
PukiWiki
PukiWiki/1.4
PukiWiki/1.4/Manual
PukiWiki/1.4/Manual/Plugin
PukiWiki/1.4/Manual/Plugin/A-D
PukiWiki/1.4/Manual/Plugin/E-G
PukiWiki/1.4/Manual/Plugin/H-K
PukiWiki/1.4/Manual/Plugin/L-N
PukiWiki/1.4/Manual/Plugin/O-R
PukiWiki/1.4/Manual/Plugin/S-U
PukiWiki/1.4/Manual/Plugin/V-Z
RecentDeleted
SandBox
SltVA
VariableArray
WikiEngines
WikiName
YukiWiki
advcal20161205
advcal20161206
advcal20161209
advcal20161210
advcal20161215
eoml0001
eoml0002
essen_ex01_0001
impressions
kcl_malloc
khfdpl_result1
members
memo0001
memo0002
note0001
note0002
note0003
note0004
note0005
note0006
oldworks
oldworks00
oldworks06
oldworks12
oldworks13
osaskjp_index
persistent_C
populars
pr20161105
pr20161105b
scsc
seccamp2017
spam_test
uxf
uxf_01
uxf_02
uxp
* 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
タイムスタンプを変更しない
* 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
テキスト整形のルールを表示する