しらいです。

In article <YAS.04Mar9232138@kirk.is.tsukuba.ac.jp>,
Yasushi Shinjo <yas@is.tsukuba.ac.jp> wrote:
>新城＠筑波大学情報です。こんにちは。

>・strlcpy() を「正しく」使うと、strcpy() を使えば生じていた
>  ようなバッファオーバーフローが完全に防げる。
>・strcpy() を strlcpy() で置換えるように書き換えることは、比
>  簡単である。
>・strlcpy() を「正しく」使うことも簡単である。

　関数とて所詮道具に過ぎない訳で、正しく使えば正しく動くし、
使い方が正しくなければ期待通りに動かないのは当たり前ですね。
問題はその「正しく使う」ための容易さの程度ということでしょう
か？
　strcpy() だって正しく使えば buffer overflow なんて起こり得
ない訳ですが、buffer size に対する指定がない分、使う側が意識
的に注意しないといけないので「正しく使う」のがより困難だとい
うことですね。
　なのでやはり程度問題でしょう。正しい関数と間違った関数とか、
完璧に bugless な関数と buggy な関数とか、そういう対比ではな
くて、単に、危険回避がより簡単に出来る関数とより簡単に出来な
い関数という相違でしかないと思います。


>> 　この辺りは言葉の綾もあるかも知れませんので、本人が自覚さえ
>> していれば構わないのですが、言葉だけが一人歩きしてしまうと、
>> 「strlcpy() を使うと security 上の弱点に繋がる bug は起きな
>> い」という思い込みが蔓延してしまい兼ねません。
>
>自覚ですか。私は、自覚とか根性とか気合いとか、そういうのでは
>なくて、何か工学的に再生産可能なノウハウで安全なプログラムを
>書きたいわけです。

　勿論、どっちのアプローチもあって構わないと思います。bottom
up なアプローチだと使う側の精度を期待する訳ですが、top down
なアプローチでは枠組の側の精度を期待する訳ですね。
　ただ、programming という分野では使う側に要求される skill が
高度なので、fool proof 過ぎる設計は馴染まないと思います。
　どこの誰が組んでも絶対に bug の入り込み得ない計算機言語なん
てあったら確かに理想的なんでしょうけど、それを実現するコスト
を考えると使う側の精度を上げた方が安上がりかと。

-- 
                                               しらい たかし