OpenBSD/2007/01/05/uimへの反応。
race condition は F_SETLKW で lock しているのでたぶん大丈夫かなと思います。
ファイルを開くタイミングの話ではなく、
開こうとしているファイルの安全を確認してから開いているかどうか、
という意味で書いたのでした(これもrace conditionの範疇です)。
- 第三者に予測可能なファイル名をもつファイルを、
- regular fileかどうかのチェック、ファイルownerのチェックを行わず、
- fopen(fn, "w")で
開いているので、どうなんだろうな、と思ったのです。
が、skk.cを良く読んでみると、
skk-uim-personal-dic-filenameと同じディレクトリにファイルを置くので、
これはおそらく問題ありません。私の誤読でしたので訂正します。
ところで、uim-helper.cのuim_helper_get_pathnameと
prime.cのprime_get_ud_pathは、"/tmp"上に作るので、
こちらは上記の問題があるのではないでしょうか。
popen の方は alphabet 以外の文字は渡らないようにしてありますがどうなんでしょう?
popen(というよりsh)のglobbing ruleを気にするくらいならば、
昔ながらのfork, exec, pipeをすべきではないでしょうか。
これだと、それぞれの段階でエラー処理を制御できるので、
問題点を洗い出しやすいコードになるのではないかと思います。
一方、popenでは満足なエラー通知はできません(OpenBSD-man:popenのBUGS参照)。
OpenBSD/2007/01/04/uimの続き。
ホスト名に環境変数SKKSERVERを無視して指定できるようにした。
これでサーバのデバッグが簡単になる(全世界の0.1%以下の人向け)。
skkdic->hostnameのメモリリークがあるかも。ちょっと自信がない。
それはそうと、skk.c全体を見るに、
rskk_save_personal_dictionaryはrace conditionを起こせそうだし、
popenしている所もちょっと危うげですな。暇があったら直そう。
uimその後
OpenBSD/2006/12/30/uimの続き。
http://slashdot.jp/~YamaKenZ/journal/387552
にて捕捉。
タレコんだのだれだ？私じゃないよ。
ipv6対応について
1.5.0へ取り込まれるとのこと。
ところで、getaddrinfoの無い古いシステム向けの代替関数実装ってありますでしょうか? 現状のuimは移植性に関してかなりいい加減なんですが、SigSchemeの導入を起点として非POSIXな組み込み環境等にも対応できるようなまっとうなコードにしていきたいと思っています。なので、伝統的socket APIへの汎用のwrapperが存在しない場合はHAVE_GETADDRINFOで実装を切り換えられるようなコードへの書き変えをお願いできないでしょうか?
skk.c以外でもネットワークを利用する可能性があることを勘案すると、
下手に#ifdefを加えるよりもgetaddrinfoをuimに追加した方がいいと思います。
openssh-portable
の
openbsd-compat/fake-rfc2553.{h,c}
をコードツリーに追加し、両コード上のHAVE_*をuim/config.h.inに追加すれば、
opensshの動く処理系上での動作が保証されることになるでしょう。
一応パッチを更新しておきました:files:patch-uim_skk_c
今回のパッチは無駄な空白の削除と、接続にipv4, ipv6のどちらかを強制させるかどうかをuim-prefで設定できるようにする変更を含みます。
インジケータについて
あ、すいません。既にbridgeのインジケータをいじるという前提の話でしたね。
context-propagate-prop-list-updateの中でcontext-current-modeの結果に応じてbridge-show-input-state?をいじれば動きそうな感じです。
こうですか！？わかりません＞＜
$ cat ~/.uim
;; -*- scheme -*-
(define bridge-show-input-state? #f)
(define bridge-show-input-state-time-length 0)
(define context-propagate-prop-list-update
(lambda (context)
(let* ((widgets (context-widgets context))
(branches (map widget-compose-live-branch
widgets))
(widget-config-tree (apply string-append branches)))
(if (eq? (context-current-mode context) 0)
(set! bridge-show-input-state? #f)
(set! bridge-show-input-state? #t))
(im-update-prop-list context widget-config-tree))))
うまく動作するように見えるのですが、
直接入力へ戻るときに、インジケータが消えてくれません(しかも内容が|あ|のまま)。
たいていのソフトではフォーカスを移してやると消えますが、
firefoxに至ってはアクティブウインドウを切り替えないと消えません。
wmはfvwm, pwm, twm, mwmでこの現象が再現されました。
nostromo httpd
先のエントリSecurity/2007/01/01/we-love-security関連で。
同様のスレッド
http://marc.theaimsgroup.com/?t=116737618200001
にて紹介されていたのでメモ。
BSDLで、
chroot, setuid, basic authentication, cgi, ssl, ipv6, alias, virtual host等、
基本的な機能はひととおりあるらしい。
内部的には、OpenBSD-man:select(2)を使っていたり(やや古風)、
mathopdと同じような方向性か。
こちらの方が機能が多いけど。
*BSD界隈でもOpenBSDのみportがあるみたい。
配布ページのグラフを見るかぎり、
けっこうスケールしているようにも見えるのだけど、
だ〜れも使用レポートを書いていない。誰か試して。
清々しいコメントを見かけたのでメモ。
marc-openbsd-ports:116759198530337
Its the current
trend of people writing software and putting "secure" into its feature list
as if that is all it takes to make it secure.
設計の段階でセキュアにしないと後で面倒なことになるよね(セキュリティとはプロセスってこと)。口先だけではダメ。
以下雑感なのだけれど、
セキュアなコードを書くのにはやはりちょっとした訓練が必要なんじゃないかなあ、
と最近は思うようになってきた。
要はバグの無いソフトを書く、というただそれだけことなのだけど、
そのことは、いわゆる「動けばいい」ソフトウェアとか、
「ベンチマーク専用」ソフトウェアとは簡単に相容れるものでは無いのだな。
それに、セキュアなソフトウェアの設計はプログラムの目的から外れるので、
おもしろくもないし、おまけに地味だ(コードレビュー、コードレビュー……)。
最近はお金になるらしいけど、
これって成果物の品質向上へのインセンティブになるのだろうか。うーん。
きましたな。
いままでのOpenBSDのxorgはdriはあるがdrmは無いという悲惨な状態だったのだけれど、
これによるパフォーマンスの向上は期待していいのだろうか。
ところで、xenocaraってなんだろうと思ってぐぐると、
こんな魚らしい:xenocara画像。
微妙。
![[image]](http://quasiquote.org/images/feed-icon-12x12.png){kind=icon}