はじめてのにき

_ SELinux

なーんとなくおぼろげにつかめてきた。 カンで書く。

• SELinux とは。 linux kernel でなんかプロセスのやることにセキュリティコンテキストベースで制限とかがかけられる。
• ls -Z とか ps Z でどいうセキュリティコンテキストのファイル/プロセスかがわかる。
• ポリシーを手動でセットしていくのは大変なので hoge.te, hoge.fc を書くことによって make で作れたりするようになってる。
• さらに reference 設定として配布されてるものがあって、かつそれは distribution が改造して適当に配布している。
• strict mode では基本全てのプロセスが何もできないのがデフォルトだけど、それは結構真剣に不便なので targeted mode とかいうヤツが普通のディストリビューションでは使われていて、それだと特定のプロセス(要はサーバ)だけできることを減らす、というような感じでできる。
• targeted で特に何も指定してないプロセスは unconfined_t とかいうのがついて、何でもできる。
• あとたぶん MLS とかいうのもある、がなんか軍とかで機密データは大佐以上がアクセス可、とかそいうヤツぽい。
• プロセスのやることを制限する書式は基本的に whitelist 方式。

さて、やりたいことは unconfined_t からほんの少しだけ権限を奪った、 つまり blacklist な感じの policy を作りたいんだけど、 あんま簡単ではなさそうなんだよな。 unconfined_domain_noaudit ってマクロが /usr/share/selinux/default/include/system/unconfined.if にあるから、 これをコピってから必要な制約だけつけないようにする、って感じかなぁ。

なんか allow kern_unconfined ~{ setpgid } とかそいうのかも

(05:19)

_ ゴルフ場 sandbox

前回までのあらすじ: SELinux はたいへん難しかった

メンテ性考えても kernel module の方が はるかにマシなんじゃないかという結論に至り、 その方向でやってみたい。 方針としてはややこしいのを書くと 大変なことになりそうなので、 間違えようのないくらい簡単なものにする。

• setuid, setgid, setsid, setpgid は root 以外は EPERM 。
• accept, bind, listen, socket あたりは…禁止したいけど、 execution server 自身の通信ができなくなるんだよな。とりあえず保留かな。
• exec の実行回数を記録しておく。
• getpriority(1764, __NR_execve) で exec の実行回数が帰るようにしておく。
• setpriority(1764, __NR_setuid, 0) とかで EPERM な system call が実行されたかをリセットして getpriority で取得。
• setpriority(1764, __NR_getpid, pid) で setpid 。
• setpriority(1764, __NR_setpriority, 0) だけは禁止。これのカウントで exec 回数の記録が捏造されてないかをチェック。

こんな感じでどうかなぁ。 やってみよう

(22:46)

_ ワンライナー自体が quine

今のところ普通に

perl -e'$_=q(printf"perl -e%c\$_=q($_);eval%1\$c$/",39);eval'
ruby -e'eval Q="puts %(ruby -e%ceval Q=%p%c)%[39,Q,39]"'

あたりが短いんだけど、 なんかまだまだ気の効いた方法はありそうだなぁ。

お、これとかちょっと気が効いてるね。

ruby -e"eval Q=%(puts %(ruby -e%p)%%(eval Q=%%(%s))%Q)"

(02:03)

_ なにかおかしい…

と思ったら一箇所 single qoute にできるんだね。

ruby -e"eval Q=%(puts'ruby -e%p'%%(eval Q=%%(%s))%Q)"

(02:04)

_ Jeff Dean's talk

http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf

ぱっと読んだかんじ

• a web search touches 50+ separate services, 1000s machines
• BigTable Coprocessors
• Spanner

あたりが喋っていいんだなぁリストに足された。

Spanner は何かとんでもないものが作られようとしているというイメージ。

最初の数字は google 入って結構びっくりしたことの一つだった。 あんだけ速く検索できるんだから すごくチューニングされた少数のマシンが返事してるのかなぁと 漠然と入る前は思っていたのだけど、 実際にはえらいたくさんのマシンがかかわってたのであった。 まぁ冷静に考えるとネットワーク速いわけだし、 あたりまえという感もあるのかもだけど…

(02:35)

_ ファイル書き込み

tmpfs を使う実装に変えた。 これでたぶんファイル残すのはかなり大変になったと思うので、 ファイル書いたと思われる投稿は消した。 具体的には hello.rb 12B * 3 だけなんだけど、 他にもあったかなぁ。

(03:17)

_ SELinux

本題の SELinux のお勉強は相変わらずわけわからんなーと思ったので、 SELinux 知ってる人いますかーと聞いたら みんな無効化したことはあるということだった。

Google suggest とかも SELinux に対して、 「無効」「停止」「無効化」などの 愛があふれる単語を suggest してくれると教えてもらった。

それでそういえば hamajis に対して 「浜地慎一郎 google」とか出してきやがるのは どうなんだとかいう話をした。

でまぁ TTEdit という ttf を手軽にいじれそうな ソフトを教えてもらって、 それは CSV からの import とかができるのが なかなかいい感じだったのだけど、 どうも小回りがきかない感じはあるのであった。 例えば UnitsPerEm をキリのいい数字にしたいのだけど、 できないぽかった。

まぁそんなこんなで 5x5 font を ベースにして TTF を作ってみたりした。 chrome で見るとどうにも文字の左右に色が見えるなぁ。 それは Ahem でも同じことだから、 Layout tests 走らせてる時はそのへん無くなるようにとかしてあるのかなぁ。

なんにせよ TTEdit 使って CSV から import するのは結構めんどくさいから、 Ahem ベースで fontforge-dev で作れたりするといいのかな。

つか Ahem 作った時のスクリプトとかがあれば手っ取りばやいのだけど。

http://hixie.ch/resources/fonts/iw-generator.py

はなぜ 500 なんだ

(04:05)

_ fetchmail

英語風設定ファイルを自慢げに書いていたのは伽藍とバザールだったか…

http://www.tlug.jp/docs/cathedral-bazaar/cathedral-paper-jp-8.html

(04:38)

_ signal

http://d.hatena.ne.jp/w_o/20091018

signal はみんなだいすき。 とりあえず練習として書いてみる。

#include <signal.h>
void (*signal(int signum, void (*handler)(int)))(int);
void static (*(* const signalp)(int, void (*)(int)))(int) = &signal;

あまりすらすらとは書けなかった… const の位置の尋常じゃない違和感といったら!

typedef は storage-sepecifier で、ヘンな位置に書けるとかいう話。

int typedef i;

とかは中置演算と考えれば読みやすいかもとかいう話だったんだけど、

int* typedef ip;

とは書けないので、まぁダメダメなのであった。

int const typedef * const i;

struct {
    int x;
    int y;
} typedef pos;

もげもげ

(05:42)

_ SSE一覧

http://krypton1.at.infoseek.co.jp/x86/x86ext.htm

ちょうべんり

(14:37)

_ Core 2 Duo

と単純にいっても色々あるわけだ。

http://ja.wikipedia.org/wiki/Intel_Core_2

今のメインマシンの R61 は…

Intel(R) Core(TM)2 Duo CPU     T7250  @ 2.00GHz (FSB=800MHz, L2=2MB)

次期ゴルフ場にしようとしてる X60 は…

Intel(R) Core(TM)2 CPU         T5600  @ 1.83GHz (FSB=667MHz, L2=2MB)

会社の X61 は…

Intel(R) Core(TM)2 CPU         T7300  @ 2.00GHz (FSB=800MHz, L2=4MB)

まくぶくはスペックからの推定だけど、

T7200  @ 2.00GHz (FSB=667MHz, L2=4MB)

このへんは全部 Merom とかいうヤツで、 全部まぁ実に似たようなものなのであった。 Core 2 Duo マシン 4 台とか持ってるという事実にも、 それらのスペックが似たようなもんという事実にも、 悲しくなるのであった。

ああでも会社の Mac Pro はたぶん SSE4 とかある感じかな。

(17:22)

_ 検索がうまくないという話

なにか僕は絶望的にヘタな検索をするという話をよくする。 けど具体的にどんなヘタ検索だったか覚えてなかったので、 適当にログをあさってヘタそうな検索失敗例を探してきた。 たいてい単語が足りてなくて増やすのだけど、 増やす前の検索キーワードで目的のものが見つかるはずがない。

• DS => カルドセプト DS
• MT => MT mersenne
• 永田 => 永田 赤軍
• span => span style => span style height
• NTT => NTT goo

あとは何が知りたかったのか見当もつかないようなクエリが たまにあるはず…と思ったのだけど、意外となかった。 不意に「はらへった」とかで検索してた気がするんだけどなぁ。 本気で意図がわからなかったのは、 「財布」「店主」などがあった。 「雪歩shinh」というのもあったが俺は一体何を期待していたのか。

あとはどんなの出てくるかなー的に検索してみたのがあるな。 「学会 エロゲ」「彼女ほしい」「エロ動画」など。 そうそう「プロフ 姫 闇」も。

(00:48)

_ YAML問題は

結局 JSON module が入ってれば JSON 使って落とすことによって解決することに。

http://github.com/shinh/caddy

rm ~/.golf/ag/Count\ diamonds\ level\ *.db

とかしてから caddy update すればたぶんうまくいきます。

しかしまぁ今回で YAML はやっぱ ムダに機能多すぎだよなーという思いを強くした。 まぁ手で書きやすいのはいいんだけど、 お手軽シリアライザとしては JSON の方がいいのかもねえ。

本当は inspect => eval でもいいんだろうけど、 まぁ eval はちょっと恐い気もしたので。

さてここで問題です。以下のコードがあって、

eval(s.inspect)

• s を自由な文字列から選べる時、任意コード実行可能な抜け道はあるか
• s を自由な ruby オブジェクトから選べる時、任意コード実行可能な抜け道はあるか

できなさそうな気がするけど、 できるとしたら kurimura さんとかが すぐに発見してくれそうな。

(01:16)

_ require 'yaml'

YAML モジュールむずかしいぞ…

http://d.hatena.ne.jp/shinichiro_h/20090826#c1255355058

をなんとかしようとしてる。

まず parser か emitter にバグがあるのは確実。

require 'yaml'
o = "-\n \n-"
p o == YAML::load(YAML.dump(o))

が false を返すのだから。

• parser は literal や fold 形式の中に空白だけの行があると空白を落とす。
• emitter は空白だけの行がある文字列を literal として出力する可能性がある。

のいずれかがバグ。調べてないけどたぶん普通に考えて前者。

とりあえず parser のバグ直すか…と ruby の中に入ってる syck のコード読んだんだけど… えっとこれ yacc で生成されてるんだよね なんでオリジナルの gram.y とか token.re とか入ってないの…

そして _why 失踪につきオリジナルのコードとかどこにあるかよくわからず。

というわけでそっちはとりあえず諦めた。

まぁなんにせよ修正は emitter 側でやった方がいい。 Ruby の修正が入るの待つより サーバだけ修正した方がいいからね。

で、まぁ…

class String
  def to_yaml_style
    :quote1
  end
end

とかしたら良いように思うのだけど、 全然 quote1 にしてくれません! なんかコードが複雑怪奇なんだけど、 複数行に渡ってると literal にするってのが優先されてる感じかなぁ。

あと YAML::Syck::Scalar#style= というメソッドもあるみたいだけど、 これをどう使うかとかはさっぱりわからない。

あとこの rdoc で何がわかるのだろう。

http://doc.okkez.net/191/view/method/Object/i/to_yaml_style

で、なんか syck を見つけた。

http://github.com/indeyets/syck

token.re 読んでたらなんとなくわかってきた… よしなおった!

diff --git a/lib/token.re b/lib/token.re
index 9d9c855..4d16363 100644
--- a/lib/token.re
+++ b/lib/token.re
@@ -308,6 +308,7 @@ TAB = "\t" ;
 SPCTAB = ( SPC | TAB ) ;
 ENDSPC = ( SPC+ | LF ) ;
 YINDENT = LF TAB* ( SPC | LF )* ;
+YINDENT2 = LF TAB* SPC* ;
 NULL = [\000] ;
 ANY = [\001-\377] ;
 ISEQO = "[" ;
@@ -966,7 +967,7 @@ ScalarBlock2:

 /*!re2c

-YINDENT             {   char *pacer;
+YINDENT2            {   char *pacer;
                         char *tok = YYTOKEN;
                         int indt_len = 0, nl_count = 0, fold_nl = 0, nl_begin =
 0;
                         GOBBLE_UP_YAML_INDENT( indt_len, tok );

でも parser 直しても意味ねー。

うーんどうやったら quote 文字列とかで出力してくれるかって話ですね…

(08:42)

_ とりあえず

パッチはちょっと修正して今のメンテナっぽい人にメールしておいた。

んなことより emitter ですね… 別の yaml ライブラリ使うかねえインストールするの面倒だけど…

(09:26)

_ stack_ni_yasasii_free_tree

http://www.tees.ne.jp/~sin-x/200910b.html#1201

を見て結構 tree で空間を定数しか使わずに、 かつ計算量 O(N) で free するのって たぶん結構難しいよねーと思って書いてみた。 実際結構難しかった。

http://github.com/shinh/test/blob/183dec99c9f05642488820587bf9e1aa48de94ea/free_tree.c

もちょい綺麗に書けたりするのかなぁ。 あとそもそも間違ってたりすると恥ずいけど、 たぶんあってるよね…

あと free_LIST は

void free_LIST(LIST *list) {
    if(list){
        free(list->name);
        LIST* next = list->next;
        free(list);
        free_LIST(next);
    }
}

としてやれば gcc なら再帰の形のままで stack ni yasasiku なるという話もありますね。

(08:44)

_ まーじゃん

やった。 一晩やってとんとんだったから成績としてはよかったんだけど、 切り間違えとかおかしいリーチとか多かったのはいまいちだった。

あと三色同刻ができたのがうれしかった。

赤入りはただでさえクソゲーの麻雀がさらにクソゲーになると思ってるんだけど、 手作りの楽しみは減るけど、押し引きが際立つ感じはあるかなぁとか思った。 麻雀ってどうせ一点読みとかはそうそうできないので、 上がりに行くか降りるかの判断が一番重要かなぁと思ってるんだけど、 赤入りだと要はドラが2個あればクイタンでもいいから上がりにいって、 1個もなければすぐ降りる、みたいな感じで適当にやってもよくて、 まぁ結局相手が高そうかどうか考えるとかする必要がなくてアレなんだけど、 すぐに降りちゃうヘタレとしては頻繁に降りておいて たまにドラあると攻めていくみたいなのがやりやすいなぁとか。

(18:43)

_ なるほどなー

http://d.hatena.ne.jp/kurimura/20091012/1255340288

紙に書いてしばし考えないとわからなかった。

要は tree を単なる list に変換しつつ 単方向 list になった時点で削除してる、 っていう感じだなぁと僕なりに理解した。

(19:14)

_ ゴルフ場

とりあえず tmpfs 使ってみる実装にしてみた。 基本的なチェックはしたけど、まぁそれなりに動いてそう。

やってて思ったんだけど、 dmesg とかに情報残すのは依然として可能だよなー。 まぁ 5B hello とかはできんくなるからいいけど…

あとは process group 一掃するようにするとか setpgid や setpgrp の禁止ってのがあったなぁ。

(23:06)

_ ふりー

http://www.tees.ne.jp/~sin-x/200910a.html#0901

どうでもいいけどこの free_LIST は 要素数多いとスタック喰い潰して死ぬのが初学者には厳しそうな… とか思った。

(05:20)

_ ばぐれぽ

http://www.kt.rim.or.jp/%7ekbk/zakkicho/09/zakkicho0910a.html#D20091010-2

glibc といえば Ulrich とかなのですかね…

(13:10)

_ XSS

そういえば XSS で今までに発生した一番深刻な被害ってなんなんだろう と思ってちょっとぐぐってみた。

たぶん cookie 盗まれてログイン情報乗っ取られて、ぼくのお金が… みたいなヤツかと思ってたんだけど、実際あるんだろうか。

と思ったらなんか cookie 盗まれるだけではすまないらしい。

http://itpro.nikkeibp.co.jp/article/NEWS/20061113/253479/

ああ単にユーザ情報収集に使われちゃうよって話か。 これもまぁクレジットカード番号とか入れてたらヤバいわけだけど、 自前でサイト作るのに対して 他人のサイトの XSS 使うメリットは URL に信用されてるドメインが使えるとかなのかな。

(13:35)

_ バグ報告とか

なにやら大変面白い話が。

http://d.hatena.ne.jp/IwamotoTakashi/20091006/p1

http://d.hatena.ne.jp/ku-ma-me/20091010/p1

http://akimoto.jp/blog/2009/10/08/bug-report-in-foreign-language/

個人的な感覚では、オリジナルの報告者の方も 最初に close した PHP の人も、 その後のいやこれは dup じゃないんだという主張も、 その後の直してくれるまでのやりとりもごく問題ないように見えるかなぁ。

なんか気になるとしても本当に細かい点で。

指摘されてる通り、 オリジナルの報告者が謙譲しすぎっていう点については、 これ要するにパッチには自信無いけどたぶんこんな感じでいいよね、 って言いたいってことなんだと思うんだけど、 まぁそいうのはよくあるからきちんとそう書いた方が 良かったかなぁというかんじはする。 これだとレポート自体に不穏な空気を出してしまうのはそうだし。 でも本当にこんなのは細かい点で。

あとは最初の php.net の人の応対だけど、 まぁどれと dup してるかくらいは言ってよ、 って感じではあるけど、 これもこの対応見るだけで判断すると、 そんなにひどい応対とは思えないなぁ。 仮にこのバグを reopen して、もう一度理由を示されず close されてたとしたら それはひどい人だと思うけど、 この程度だったらまぁ忙しいプロジェクトの バグ管理とか多少雑になっちゃうのはしょうがないと思う。

バグの数が50000とかになってるプロジェクトなんだから (10年やってるわけだけど単純計算で1日10個とかだよねえ…)、 多少ミスがあるかもしれないけど適当に バグの dup 判定とかをざっとやって、 それでお前それ違うヨ! って言われたら もうちょっとちゃんと判断する、みたいな 雑なスキームになっちゃうのはしょうがないように思う。

だからこの応対だけではこれはひどいとは思えないかなぁ。 懇切丁寧な方がそりゃいいんだけど。

でまぁ、エスパーじゃあるまいし実際そいう事情があるかは知らんので、 報告者の方がそのへんを察するべきだった! とかいう主張をする気も全くなくて、 絶望した! とか思っちゃうのもしょうがないと思う。 それでもちゃんといやこれ dup じゃない気がするんだ と言ってるのもすごくいいと思う。

そんなこんなで僕的にはごく普通の bug repot → fix の流れのひとつに見えたようにおもう。

ちょっと改善できたらいいかなぁと思ったのは はてぶとかしてる人で実際に PHP のそのバグを 困るものとわかってる人は、 バグに対して賛意を示してあげたりすると目立つからいいと思うんだよな。 できれば補足説明とかしてあげられるといいけど、 "+1 for this bug" とかだけでもいいように思う。

あと個人的には秋元さんの意見には 一般論としてはあまり同調できないなぁ。 そういう(すごく丁寧に説明する)やりかたも アリっちゃアリだとは思うんだけど、 個人個人のリソースは限られてるんだし、 適当に短いバグレポートをほってみて、 それだけで直してくれたらラッキーだし、 反応が無いようなら重要度に応じてあきらめてみたり ping してみたり、 伝わってない部分があればそこを細かく説明してみたり、 という感じで適当にやればいいんじゃないかなぁ。 伝えるのが難しそうなら日本語でブログ書いて応援求めるとかも すごくいいように思う。

例えば英語とか書きたくなければ、 there is a bug: <再現するコード>, expected: <hoge>, actual: <bug!>、 とかだけでもたぶん良いわけで。 実際 WebKit のバグとか見てる感じでは、 最悪再現する URL だけでも良くて、 できれば再現する最小の html なりなんなりにしてくれると良くて、 さらにそのまま test として使える程度にわかりやすい html だと (緑になるべきだけど赤くなるとかそういうやつ) なおよい感じかな。

直す側に回る時はそのバグの深刻度とかは 正直どうでもいい情報でしかなくて、 開発者側の priority 見積りは信用できないから 急いでなおして欲しい! と思うなら書く、 くらいでもまぁいいんじゃないかなぁ

そいう意味で秋元さんご自身のバグレポートの例それ自体は、 これはこれでこの事情ならこのくらいきちんと説明しないと ドコモのほげほげの事情とか知らんだろうし、 丁寧に説明しておられたのはそれはそれで適切な気がした。 普通に考えるとそんなよくわからんバグに priority あげられないからねえ。

(17:59)

_ base85

というものがあるようだ。

http://tools.ietf.org/rfc/rfc1924.txt

Git がこれ使って binary diff を作ってるみたいなんだよね。 自分で書きたくないから素直に base64 使って欲しいなぁ…

(02:50)

_ std.format

import std.format;
import std.stdio;
import std.string;

void main() {
    stdout.writeln(format("%c", 'a'));
}

ぎぎぎ %c が無いぞ… よくわからんけど今度パッチをほる

(01:41)

_ ふうせんおじさん

http://darwinawards.com/darwin/darwin2008-16.html

ブラジルにもいたらしい。 GPS持って出発したけどGPSの使い方がわからなかったらしい。

(18:50)