どさにっきクラウド 〜2009年1月下旬〜

by やまや
<< = >>

2009年1月22日(木)

きょうのあなごる

_ Up and Downを bash で。サイズを縮める前にまず動くものを作ってみたけど、やっぱり 予想どおり遅すぎて話にならん。文字ごとに分割して tr に食わせるなんてやってたら速くなりようがない。が、それ以外に方法あるか?

read s
while IFS= read t;do
    for i in `seq 0 ${#s}`;do
        c=${s:$i:1}
        case "${t:$i:1}" in
        +)r="$r"`tr \ -} !-~<<<"$c"`;;
        -)r="$r"`tr \ -} '\37-|'<<<"$c"`;;
        *)r="$r$c";;
        esac
    done
    s="$r"
    r=
done
echo $s
↑bash で linux じゃないと動かん。

A-Z

_ そういえば上のスクリプトでは tr による変換文字をを8進数で指定してる部分があるけど、man によるとこんなふうに範囲指定で8進数を使うと必ず ascii コード順になることが保証されるらしい。知らんかった。

_ どういうことかというと、範囲指定は実はロケールに依存するので、A-Z が ascii コード順の ABC...XYZ になるとはかぎらず、ロケールによって並び順がさまざまに違うことがありえるけど、あえて8進数で \101-Z と指定することによってロケールに関係なくアルファベット大文字だけを指示できる、ということ。いや、ほんとは [:upper:] で指定するのが正解なんだけどね。ただ、[:upper:] だと大文字ぜんぶになっちゃうので A-C だけが欲しいときとかに困るし。もっとも、それならそうで文字の並びが ascii コード順になってるロケールに切り替える (LC_COLLATE=C) のが正解なんだろうけど。つーか、FreeBSD の tr の man にそう書いてあったというだけで、他の実装の tr でどうなるかとか、FreeBSD でも tr じゃなくて sh で [A-Z] のかわりに [\101-Z] と書けるかどうかとは知らん。要するにできるからといってホイホイ使うな、ということだな。

_ アルファベットの並びが文字コード順になってないロケールによる ハマリ例。実はつい数日前近所でも話題になったんだけど、これはバグではなくて正常な動作。en_US ではアルファベットが ABC...XYZabc...xyz ではなく aAbBcC...xXyYzZ と並んでいるので、A-Z というのは a 以外のアルファベット大文字小文字という意味になる。まあ、たしかにハマりやすい罠ではある。

_ つーか、tr の文字コード指定ってなんで8進数なの? 10進や16進じゃダメなの?


2009年1月26日(月)

それ意味あんのか

_ ほげでふがするための10の方法、のようなタイトルの記事にはロクなものがないの法則。ありがちなのは、10のうち3つはそんなの幼稚園で習ったよねというぐらい前提レベルが低すぎて、3つは幼稚園レベルでないにしても知ってて当たり前で、2つはわからんでもないが自分ところの環境では制約があって使えなかったり副作用があってやるやらないを慎重に検討せずに鵜呑みにすると後で痛い目を見て、ひとつはトリッキーなわりに効果が薄くて、そして最後のひとつは内容が間違ってる。全部が全部そうだとは言わんがね。

_ Apacheの安全を確保するための10の対策。あまりにアレなので最初の方は見出しだけ見て、#9 を苦笑いしながらさらっとスルーしつつ(←スルーできてない)、でも最後の #10 はスルーできなかった。まだ耐性が低いな。

#10: httpd.confを変更できないようにする
 httpd.confを詮索好きな目から隠すことは、セキュリティのための最善の方法の1つだ。見るべきではない人がhttpd.confを見ることができないようにしておけば、それを変更されることもない。
これ、元記事を書いた人もそれを翻訳した人も疑問に思わなかったんだろうか。詮索好きな目から隠す、っていうから読み取り権限を落とすのかと思ったら、書き換え禁止する方向に話が変わってますよ。たったの2文でどーして文意が大転換するの。

_ しかも、その書き換え禁止の方法が chmod a-w ではなく chattr +i というのがなぁ。これをやればたしかに root ですら書き換え不能になるけど、chattr -i すればまたいじれちゃう。意味ないんじゃね? *BSD の chflags schg だったらカーネル側で securelevel を上げれば root ですらフラグを解除できないようにすることもできるけど、Linux にはそんな仕組みはなさそうだし(それとも man にないだけでちゃんと方法はある?)。

_ つーかさ、もともと root 所有で root 以外に書き換えできないようになってる httpd.conf を一般的な chmod じゃない方法を使ってさらに守るってのは、そのホストの root が誰とも知れない第三者に乗っ取られた後のことを意図してるんだよね? でもそんな root を取られたホストで httpd.conf だけ無傷で残ったところでうれしくも何ともないよ。httpd.conf をいじれなくても、起動スクリプトの方を httpd -f /var/tmp/hogehoge に書き換えられちゃったり、httpd の実行バイナリ自体を置き換えられたり、あるいは httpd 以外のほげほげやふがふがを乗っとられたり何されるかわからんでしょ。httpd.conf の修正ができないようにすることで何を守れるかってのがはなはだ疑問。

_ ま、でも httpd.conf を変更できないようにするのは大事よ。とある共用レンタルサーバで httpd.conf がなぜか root ではなく apache 所有になっていたために、suexec でないユーザの CGI から httpd.conf を変更されてしまって httpd 再起動と同時にあぼーんという事件が以前あったらしいから。でもそんなことの対策は chattr なんか使わずとも、インストールしたときの状態そのままでいいんだから、ふつーは気にせんでよろしい(件のレンサバはなんでわざわざ所有者を変更してたんだろ?)


<< = >>
やまや