未来のいつか/hyoshiokの日記

TOMOYO Linuxに学ぶ説得術

昨日、TOMOYO Linuxメインライン化記念合同勉強会（カーネル読書会、セキュアOSユーザ会、まっちゃ445）に行ってきて、小崎さんが匿名掲示板でガチでレビューしていたお話を聞いたので、早速過去ログを読んでみた。http://tomoyo.sourceforge.jp/2ch/thread-2.txt

（追記：2009/7/4 21:03 なぜか後半部分、アスキーアートの後が切れてしまったので、前半部分を若干カットして（略）の部分、その２を追加しました。）

LKML (Linux Kernel Mailing List)というのはLinuxカーネルの技術的なことを議論するもっとも権威（？）あるメーリングリストで、ここで議論され合意されたものがLinuxの本体に取り込まれることになる。このLinuxの本家本元の本体（くどいな）のことをメインラインと呼ぶ。Linuxを創ったLinusさんにちなんでLinus' treeとか、アップストリームカーネルとか呼ぶ場合もある。

このメインラインに新機能を入れるのは簡単ではない。強者の開発者が納得する技術的メリットをわかりやすく説明する必要がある。その方法論というのをわれわれは学校でも教わっていないし、訓練する機会もあまりないのでLKMLでの議論を題材に説得術という観点で学んでみたい。

2チャンネルのログを再構成しながら、適宜解説などを加える。

本家LKMLの過去ログは下記にあるので、適宜参考にしてほしい。下記[1/10]とかいう表記は10個のパッチのうちの１個目のパッチについてのコメントを示す。

http://marc.info/?w=2&r=1&s=tomoyo+mmotm+2008-12-30-16-05&q=t

683 ：login:Penguin：2009/01/09(金) 22:36:28 ID:hv8sw/Ot
TOMOYOをレビューしてみた 
LKMLに投稿してもあれるだけなので、先にこちらに書く 

[1/10] 
まず、in_execveはやっぱり説得力がない。CREDのせいで出来ないと書いてあるが、 
そんならCRED直せば出来るんやろ。という話にならないのか？という疑問がわく。 
別の実装を一度つくって、Sergeにやっぱ前の実装の方がいいわー。って言わせた方がよい。 
でないと、オレのレビューを無視するのか？ならNackだーって話の流れになりかねない。 

LKMLに投稿してもあれるというのは、レビュアーとして応援したいのだけど、厳しいコメントをいっぱいするので、ここで日本語で十分もんでからLKMLに行こうというやさしい愛のこもった提案である。

Nackとは、否定の意味。提案をリジェクトすること。

以下2~10のパッチについてのコメントが続く。

684 ：login:Penguin：2009/01/09(金) 22:37:08 ID:hv8sw/Ot
[2/10] 
Singly Listも、ちょっと説得できてないようなので捨てる方向でつくり直した
方がよい。というかこういう コアピースは他のパッチのついでみたいな投稿の
しかたじゃ入らないと思う。  Linusも以前、ダメだと言っていたよ。とか言わ
れてるぐらいだし。

685 ：login:Penguin：2009/01/09(金) 22:42:49 ID:hv8sw/Ot
[3/10] 

d_realpath()はpatch descriptionがよくない。patch descriptionは何故これ
が必要なのかと、 その問題のポイントがどこだと考えているのかという話と、
どうやって解決しているのか、 の３点が必要だが、実装の説明しかない。  
また、pathname based access control difficult の一行だけで dcache.c いじ
るのはかなり無理筋。
難しいだけで、可能なんだったらTOMOYO側でやれよ。共通ルーチン部分いじんな。と 

前に誰かが、なんで d_path() ＋ ユーザランドで加工で出来ないの？とか聞いて、
そうするとセキュリティレベルが落ちるとか なんかとか答えていたおぼろげな記憶があるけど、
それがpatch descriptionに反映していない。 
つまり、新しい人がReviewするたびに、Nackが増える構造 

realpath()は悪い名前。d_path()がfake であることを連想させるけど、
そうではなく、たんにTOMOYOに 都合のいい形式のものをrealと呼ぶのは無理がある。 
他のアプリでも使えることを説明しないと、real じゃないでしょ。 
もちろん、理論上可能ってことじゃなくて、実際に d_realpath()つかって
他のサブシステムがこんなに行数減ったってパッチを書く必要がある 

chrootとbind mount時のふるまいはもっと細かく書かないとダメ。
それがあるからrootより上をたどりたくないんだから。 

ディレクトリ時に/を付加するのは、TOMOYO側で出来るはずだし、linuxのパスの
ルールではなくTOMOYOルールなので、 共通ルーチンにいれるべきではない。 

/proc/PID を/proc/self に変換してるのも同じく筋悪 

686 ：login:Penguin：2009/01/09(金) 22:49:07 ID:hv8sw/Ot
[4/10] 
crazy なファイル名に対してエンコードを施さないとどうしてsafeでなくなるのか
説明されていない。 
カーネル内にパーサーを入れることはLinusがいやがっていることもあって、
みんな気にするので もっと詳しく説明した方がよい。 

僕の感想では、たんに、ログが見にくくなるだけだったら、こんな処理入れるな。
というのが共通認識だと思う 
ログは人間がみるものなんだから、見る直前に加工すればいいじゃん。という疑問がわく。 

687 ：login:Penguin：2009/01/09(金) 22:55:16 ID:hv8sw/Ot
[5/10] 
全般的に、パーサーを入れるな方針に反しているので厳しそう。 
Ingo がftrace関係でファイル名を正規表現で指定できるようにしたい。
って以前いっていたらから 
そっちに協力して、汎用的な正規表現パス指定関数群を linux/lib 以下に作って 
そっちを使うように作りかえたらどうかな？ 

あと、 

+ case '$': /* "\$" */ 
+ case '+': /* "\+" */ 
+ case '?': /* "\?" */ 
+ case '*': /* "\*" */ 
+ case '@': /* "\@" */ 
+ case 'x': /* "\x" */ 
+ case 'X': /* "\X" */ 
+ case 'a': /* "\a" */ 
+ case 'A': /* "\A" */ 
+ case '-': /* "\-" */ 

このコメントはひどいやろ。なんの説明にもなってない。 

688 ：login:Penguin：2009/01/09(金) 22:57:09 ID:hv8sw/Ot
[6/10] 
TOMOYOのファイルだけの変更だし、パーサーもないから、誰も文句を言わなさそう。 
でもpatch descriptionが１行なのはちょっとひどい 

689 ：login:Penguin：2009/01/09(金) 22:59:52 ID:hv8sw/Ot
[7/10] 

これも6/10と同じで、完全にTOMOYOに閉じた話なので文句はつかないと思う。 
ただ、これも同じくpatch descriptionが弱い。 
TOMOYOのドメイン遷移ルールなんか誰も知らないのだから例を交えつつ丁寧に 
説明しないと、誰にもレビューできないのではないか。 

レビューされてなくても、マージされそうな気もするので、無視してもらってもよいが。 

690 ：login:Penguin：2009/01/09(金) 23:07:02 ID:hv8sw/Ot
[8/10] 

RFCならともかく、マージをめざすパッチで議論とか質問が書いてあっても、
相手が困ると思う。 
あと、security_task_free()はCredなくても事実上無意味だったはず。
task struct ってRCUつかって、 
スレッド死んだときとは違うタイミングで構造体破棄してるから、
もともと使い道なんて無かった。 
（まちがってる？） 

tomoyo_domain_info にu32 を追加する方式では何が困るかが全然書いてないので
返事のしようがないというのが感想。 

・TOMOYOのTはtaskのTなんだ 
−＞ だから何？ 
・TOMOYOにとってnightmareなんだ 
−＞結局理由かいてないよね。それってただの感想だよね 

って見えると思う 

691 ：login:Penguin：2009/01/09(金) 23:07:34 ID:hv8sw/Ot
[9/10] [10/10] はNo problemと思いまする 

ふー。ひとつひとつのパッチについて詳細にレビューコメントを書いている。すごいな。LinuxKernelコミュニティのお作法で言えばレビューコメントはLKMLでやるのが筋なのだけど、わざわざ２chでやったのは、LKMLでやるとレビュアーが否定的なことをがんがん言っているように受け取られるのが嫌だからだそうだ。建設的な議論をしたかったそうだ。英語だと自分の気持ち（応援しているんだよ）が伝わらないので日本語でしたと。なるほど。

@ITの大人気連載Linux Kernel Watch 『12月版　カーネルゆく年くる年、2009年に来る機能はどれだ？』

で小崎さんは、『ただ、筆者のようにサブシステムに関係なくReviewed-byを投下しまくっている連中からすると、TOMOYOは大き過ぎてちょっとレビューがしんどいのも事実です。』と記している。

692 ：login:Penguin ◆XkB4aFXBWg ：2009/01/09(金) 23:23:48 ID:8u0X+gul
>>683 
レビューありがとうございました。LKMLでは、投稿したとき通りかかった人が、 
意見を述べる（そして立ち去る）という感じで、単独の方から全体を通してのコメントを 
もらったのはこれが初めてです。（kosakiさんが書かれているように、全体を通してみるには 
規模が大きくなってしまったということでもあります） 

提案では「完全なパッチを目指す」というよりは、「通す（マージしてもらう）」を 
優先して考えていますが、有識者の方のご意見は進行中のやりとりや今後のパッチの参考に 
なると思います。他の方でもご意見、ご提案があれば是非お聞かせください。 

692の書き込みの『kosakiさんが書かれているように、全体を通してみるには規模が大きくなってしまったということでもあります』は上記Linux Kernel Watchの記事のことだと思うのだけど、なぜか、本人降臨。

693 ：login:Penguin：2009/01/09(金) 23:29:01 ID:hv8sw/Ot
な、なんでオイラが kosaki って分かったのさ。 
しょ、証拠はどこにあるんだ。うがががー 

2chが匿名掲示板というのはウソだな 

694 ：login:Penguin ◆XkB4aFXBWg ：2009/01/09(金) 23:32:52 ID:8u0X+gul
やはり・・・。(=_=; 

693はスルーすればいいのに。自ら墓穴を掘るとはこのことなんだな。レビュアーが小崎さんだということを認める発言。

日本発のオープンソースのプロジェクトでは、、半分匿名（ハンドル名）で開発することはそれほど珍しいことではないが、２chで超真面目な議論がこれから展開されることになる。

697 ：login:Penguin ◆XkB4aFXBWg ：2009/01/10(土) 00:00:53 ID:86I9WRb8
>>684 
>Singly Listも、ちょっと説得できてないようなので捨てる方向でつくり直した方がよい。というかこういう 
>コアピースは他のパッチのついでみたいな投稿のしかたじゃ入らないと思う。 
>Linusも以前、ダメだと言っていたよ。とか言われてるぐらいだし。 
ここで「コアピース」とは、汎用のという意味で書いていますか？ 

実際には、list1は「確かに片方向のリスト」ではありますが、 
削除なし（read lock不要)で、実質的にはtomoyo専用（固有）です。 
なので昨日Sergeへのリプライでは、 
>Thus, I'd like to rename to "rlfl" (Read-Lock-Free List). 
と返信しています。 

699 ：login:Penguin：2009/01/10(土) 04:04:54 ID:Dw+abJQq
>>697 
パッチの最小化の観点からいうとver1はlock freeを捨てて、
毎回mutexをとる作りにしてもええんちゃうの？＿ 
途中で寝たいから云々ってのはspin_lock を考えるから問題になるのですよね・・ 

片方向リストというのにTOMOYOは妙にこだわっているわけだけど、そーゆーところは捨ててもいいのではないかと。いきなり実装の細部にこだわるのは木を見て森を見ずになりがちということか。

熊猫さんの怒涛のレビューに対するコメント返しが始まる。

700 ：login:Penguin：2009/01/12(月) 16:34:37 ID:SrCsF0ph
>>676 
熊猫は木曜の夜から風邪で、ほとんど布団の中です。 

>>666 
>TOMOYOは性能だけじゃなく機能も豊富なのでいくつか落としてもいいんじゃない？ 
レビューありがとうございます。 
これでも最小限の機能なんです。（泣） 

>>675 
> ２．ただ、普通のlistを使うようにも書き直せる気がする。 
書き直せますが、 prev ポインタへのアクセスが発生するため read lock を随所に 
導入する羽目になります。 TOMOYO が巨大な割にシンプルなのは、 delete しないことで 
read lock を使わないという割り切りをしているからです。（所詮、消費メモリは 
１メガバイト以内ですから。） 

> ３．in_execveについては、実は２案検討したんだけどもう１つの案は、 
> こんなにUglyなのでin_execveのほうが、はるかにマシなんだ。 
Sarge は既に２案とも知っており、 in_execve の方がマシだと述べています。 
David Howells のコメントを求むと投稿しましたが、まだ本人からのコメントは 
ありません。本人がオンラインなのは確認ずみです。 

さて、それぞれの機能について詳細な質疑応答、議論が始まる。レビュアー対実装者（主に熊猫さん）。文中の＞＞700というのは700番の話題（700 ：login:Penguin：2009/01/12(月) 16:34:37 ID:SrCsF0ph）について返事を書いているということである。

705 ：login:Penguin：2009/01/12(月) 17:02:24 ID:fsX40d3O
>>700 

＞> ２．ただ、普通のlistを使うようにも書き直せる気がする。 
＞書き直せますが、 prev ポインタへのアクセスが発生するため read lock を随所に 
＞導入する羽目になります。 TOMOYO が巨大な割にシンプルなのは、 delete しないことで 
＞read lock を使わないという割り切りをしているからです。（所詮、消費メモリは 
＞１メガバイト以内ですから。） 

つまり、そのシンプルさがマージ議論を困難する価値があるかどうか。という天秤の問題と 
思っています。 
随所に導入すると具体的に何行増えるのか数値はもってますか？ 

もっというと他のサブシステム人はtomoyoディレクトリ以下がmessyでもあんまり気に
しないけど コアコードに見知らぬコードが入ると、消極的反対からレスをつけ始めるから
議論が錯綜しがちに 思う。 

たとえば、最初はTOMOYOディレクトリにsingly listコードおいておいて、
パッチディスクリプションに 他に使う人が出た時点で場所が移動される予定。
とか書くのはダメ？ 


＞> ３．in_execveについては、実は２案検討したんだけどもう１つの案は、 
＞> こんなにUglyなのでin_execveのほうが、はるかにマシなんだ。 
＞Sarge は既に２案とも知っており、 in_execve の方がマシだと述べています。 
＞David Howells のコメントを求むと投稿しましたが、まだ本人からのコメントは 
＞ありません。本人がオンラインなのは確認ずみです。 

ここで第三者だよりなのはなぜなの？ 
議論の進め方として悪手に見えるんだけれども。 

David Howells は絶対TOMOYOに良い方向にコメントしてくれるよう事前にネゴって
あるの？ 
で、なければ、いったんDavidは忘れてSerge攻略したほうがよくない？ 

パッチディスクリプション(patch description)とは投稿したパッチの説明を記述した文書。これによって、パッチの意図、目的などをレビューをするカーネルプログラマが理解する。従って、その書き方は非常に重要。

さらに一問一答が続く。

701 ：login:Penguin：2009/01/12(月) 16:35:45 ID:SrCsF0ph
>>680 
> 捨てられる部分かどうか、知らないけど。（特にd_realpathとか） 
捨てられません。 

過去の提案では security/tomoyo/ 以下だけの修正で済むようになっており、 
TOMOYO を使わないカーネルのためにコードが大きくならないように配慮していました。 
しかし、熊猫の記憶が正しければ、「このリストは共通部品として使えるから 
security/tomoyo/ 以下に置くよりも include/linux/ 以下に置く方が良いのでは？」 
「この処理は d_path() と同様だから security/tomoyo/ 以下に置くよりも 
fs/dcache.c に入れる方が良いのでは？」とアドバイスされ、それに従ったら今度は 
「コアコードに手を加えるな」と反発を喰らっているように感じています。 
どうせ TOMOYO しか使わないでしょうから、置き場所が問題なのであれば 
security/tomoyo/ 以下に移動させるだけの話です。 

>>683 
> そんならCRED直せば出来るんやろ。という話にならないのか？という疑問がわく。 
credentials パッチは TOMOYO が out-of-tree の状態で検討され、マージされました。 
活発な検討が行われているのは見ていましたが、 TOMOYO がマージされる前に 
credentials がマージされることは想定していなかったので、 credentials 無しの 
状態で TOMOYO の開発が続けられました。 
credentials がマージされてしまった現在でも TOMOYO は out-of-tree であるため、 
TOMOYO 側から「今までできていたことができなくなった。リグレッションだ。 
何とかしてくれ。」と要求することはできません。 credentials に影響を与えない範囲で 
workaround を探すのが精いっぱいでしょう。 

これに対するコメント返し。

706 ：login:Penguin：2009/01/12(月) 17:11:01 ID:fsX40d3O
>>701 
（略）
＞「この処理は d_path() と同様だから security/tomoyo/ 以下に置くよりも fs/dcache.c に 
＞入れる方が良いのでは？」とアドバイスされ、それに従ったら今度は 
＞「コアコードに手を加えるな」と反発を喰らっているように感じています。 
＞どうせ TOMOYO しか使わないでしょうから、置き場所が問題なのであれば 
＞security/tomoyo/ 以下に移動させるだけの話です。 

それは典型的なコメントには従ったが行間を読んでなかったってことなんだと思う。 
共通部へ移動ってのは、たんにファイルの場所を移動するだけじゃなく、共通部にふさわしい 
コードへ変えてね。って事も当然求められていると思う。 

それから、単に security/tomoyo/ に戻すってのは「おれのレビューコメントを無視するのか」 
問題が出かねないので、やりかたとやるタイミングを吟味した方がよいと思う。 

一番いいのはsingly list といううたい文句は捨てて、RCU safe list として、ちゃんとそれにふさわしい 
操作ルーチンを一通り入れてLinusを説得すること。 
レビューアーの期待値はそこだと思う。 

僕がレビューワーだったら、たんにtomoyoに移動させるだけならNackするので選択肢は 
・普通のlistを使う 
・TOMOYOの利用方法に閉じない、ちゃんとしたRCU safe listをつくってlinusを説得 
の２択と思う。もちろん前者が、easy. 

行間を読んでいない。

707 ：login:Penguin：2009/01/12(月) 17:16:08 ID:fsX40d3O
>>701 

＞> そんならCRED直せば出来るんやろ。という話にならないのか？という疑問がわく。 
＞credentials パッチは TOMOYO が out-of-tree の状態で検討され、マージされました。 
＞活発な検討が行われているのは見ていましたが、 TOMOYO がマージされる前に 
＞credentials がマージされることは想定していなかったので、 credentials 無しの 
＞状態で TOMOYO の開発が続けられました。 

過去の経緯は職業柄存じております(^^;; 

＞credentials がマージされてしまった現在でも TOMOYO は out-of-tree であるため、 
＞TOMOYO 側から「今までできていたことができなくなった。リグレッションだ。 
＞何とかしてくれ。」と要求することはできません。 credentials に影響を与えない範囲で 
＞workaround を探すのが精いっぱいでしょう。 

なぜ？ 
リグレッションでないのは確かだけれども、本当に必要ならTOMOYOのために、 
CREDをいじってもいいのであ？ 
説得できないような理由なの？ 

もちろん、CREDの人から見ると「TOMOYOのために変えてくれ」と言われたら断ると思うので 
カーネル全体にとって利益があると納得させるだけの理論武装は必要と思うが。 

繰り返すけど、コアコードをいじること自体は誰も反対してないと思うんだ。
ただパッチディスクリプションにTOMOYOの都合が書いてあると、みんなTOMOYOの事なんか
知らないから消極的反対から話がスタートしてしまうと思う。 

自分の都合だけを書いていると共感を得られないというお話。それが積極的賛成を生むのではなく、消極的反対を生む。なるほど。

702から続くスレッド。

702 ：login:Penguin：2009/01/12(月) 16:36:55 ID:SrCsF0ph
>>684 
> Linusも以前、ダメだと言っていたよ。とか言われてるぐらいだし。 
Linus が以前 No と言ったとしても、既に 2.6.28 では何十もの in-tree な 
singly linked list の利用者が存在しています。これから in-tree となることを 
目指している TOMOYO が singly linked list を使ってはいけないと言われるのは 
不公平だと思います。 
singly linked list を API として include/linux/ 以下に置くことに対して 
Linus が No と言っているのならば、 security/tomoyo/ 以下に置くことになるでしょう。 
Linus が singly linked list そのものに対して現在も No であるとしたら、何故 
何十もの in-tree な singly linked list の利用者がカーネル 2.6.28 に
残っているのでしょうか？ 

>>685 
> realpath()は悪い名前。d_path()がfake であることを連想させるけど、 
そういう感覚はありませんでした。ライブラリ関数として realpath(3) というものが
あるので、 カーネル版の realpath(2) と命名しました。 AppArmor は 
d_namespace_path() という名前を 使っているので、 TOMOYO では 
d_ns_path() あたりでしょうかね？（ /proc/self の例外扱いの 
問題があるので AppArmor と衝突する名前は避けたいです。） 

> /proc/PID を/proc/self に変換してるのも同じく筋悪 
これは d_realpath() 内でないと実装できません。 "proc/数値" という文字列と
一致したとしても 「数値部分が必ずプロセスＩＤである」という保証が無いからです。
また、 procfs が proc2 に マウントされていたら "proc2/数値" という文字列で
判定しなければいけなくなります。 
筋が悪いと言われようとも、文字列に変換後に推測して置換する方式は TOMOYO としては 
容認できません。 

708 ：login:Penguin：2009/01/12(月) 17:24:23 ID:fsX40d3O
>>702 

＞> Linusも以前、ダメだと言っていたよ。とか言われてるぐらいだし。 
＞Linus が以前 No と言ったとしても、既に 2.6.28 では何十もの in-tree な 
＞singly linked list の利用者が存在しています。これから in-tree となることを 
＞目指している TOMOYO が singly linked list を使ってはいけないと言われるのは 
＞不公平だと思います。 

まったくそうは思いません。 
今まで、数々の議論でprevメンバーを使わないケースでも、二重リストで性能劣化が 
ないから、不必要にカーネルコードを膨張させる必要ないよね。というのが結論。 

なので、今まで結論通りTOMOYOが二重リストを使うけどprevメンバは使わない状態を 
維持するなら誰からもNackは飛んでこない。 

＞singly linked list を API として include/linux/ 以下に置くことに対して 
＞Linus が No と言っているのならば、 

そうは言ってないという認識。 
いままで、Singly linked listを作るメリットを、ちゃんと説明できた人がいないので、
NOだったという 認識。 
「不必要な」コード追加はいやだ。と言われている。 

でも、Linusが一度slistはいらない。と判断したあとでいうと、サブシステムメンテナでは
ひっくり返せないので自分でLinusを説得してね。といわれるのも自然の流れ。 
いまのlist1だと説得は無理だとおもうけど、LinusはRCU好きっこなんだから、
そっちを前面に出せば説得できるんじゃないの？ 

大事なのはTOMOYOの価値観じゃなくて、コミュニティの価値観で議論・説得することだと思う。 

大事なのはTOMOYOの価値観じゃなくて、コミュニティの価値観で議論・説得することだと思う。

709 ：login:Penguin：2009/01/12(月) 17:24:44 ID:fsX40d3O
>>702 

＞security/tomoyo/ 以下に置くことになるでしょう。 

おすすめしないです。理由は１つか２つ前に書いたとおり。 

＞Linus が singly linked list そのものに対して現在も No であるとしたら、何故 
＞何十もの in-tree な singly linked list の利用者がカーネル 2.6.28 に
＞残っているのでしょうか？ 

上でも書いたけど、一番の問題は今のパッチディスクリプションに書いてある
「TOMOYOはprevメンバは使わない」ってのはまったく理由になってないということ。 
他の何十のサブシステムがprev使ってないけど二十リストでやってる状況があるから。 

「メリットがなければコード追加しない」という価値観を前提に理論武装して説得するのが
いいと思う。 

710 ：login:Penguin：2009/01/12(月) 17:33:49 ID:fsX40d3O
>>702 

＞> realpath()は悪い名前。d_path()がfake であることを連想させるけど、 
＞そういう感覚はありませんでした。ライブラリ関数として realpath(3) というものがあるので、 
＞カーネル版の realpath(2) と命名しました。 AppArmor は d_namespace_path() という名前を 
＞使っているので、 TOMOYO では d_ns_path() あたりでしょうかね？（ /proc/self の例外扱いの 
＞問題があるので AppArmor と衝突する名前は避けたいです。） 

ああ、なるほど。そっちか。 
じゃあ、「similar to realpath(3)」とか書いて、printk とか strcpy とかと同じく、 
libc にあわせた分かりやすい名前を目指しているんだよん。とかパッチディスクリプションに 
あるべきと思う。 

あと、絶対パスはネームスペース依存なんだけど、それを無視しているのが筋悪と思う。 
引数で受け取ったtaskのネームスペースでresolvするけど、NULLだったら 
グローバルネームスペース、とかflag引数を追加するとか、したほうがよい気がする。 
（fs系くわしくないので、外しているかも） 


711 ：login:Penguin：2009/01/12(月) 17:37:18 ID:fsX40d3O
>>702 

＞> /proc/PID を/proc/self に変換してるのも同じく筋悪 
＞これは d_realpath() 内でないと実装できません。 "proc/数値" という文字列と一致したとしても 
＞「数値部分が必ずプロセスＩＤである」という保証が無いからです。また、 procfs が proc2 に 
＞マウントされていたら "proc2/数値" という文字列で判定しなければいけなくなります。 
＞筋が悪いと言われようとも、文字列に変換後に推測して置換する方式は TOMOYO としては 
＞容認できません。 

この理屈は絶対ダメね。TOMOYOの理屈になっている。カーネル全体からみて、今の仕様が 
望ましいんだーーって言えるのが必須。 
少なくとも、flags 引数を追加して、TOMOYO仕様は、あるflagがONのときだけ動く、
とかそれぐらいは出来そうに思う。 

今の仕様でAckする人はいないと思う。どう見てもTOMOYO以外に使えない関数になってるもの。

TOMOYOの都合を押しているというのがダメな理由との指摘。相手に取って〜というメリットがあるからXXXとするという表現にしないと受け入れられない。カーネルにとって何がうれしいのか、どーあるべきかという説明でないとだめだ。

703のスレッド。

703 ：login:Penguin：2009/01/12(月) 16:38:11 ID:SrCsF0ph
>>686 
> crazy なファイル名に対してエンコードを施さないとどうしてsafeでなくなるのか説明されていない。 
TOMOYO の根底をなす識別子として「ドメイン名」というものがあります。このドメイン名は 
起点となる＜kernel＞という文字列に、そのドメインに到達するまでに実行された
プログラムの 絶対パス名を連結（区切りとして 0x20 を使用）したものとして定義されます。
しかし、 Linux では、 パス名には 0x20 を含めて全ての文字を使用できてしまいます。
もし、エンコードを施さなかった場合、 プログラムのパス名の一部としての 0x20 なのか、
区切り文字としての 0x20 なのかが区別できなく なってしまいます。 
かといって、区切り文字として 0x0 を使用するのは、ライブラリ関数を使えなくなるので 
大混乱を招くことが容易に想像できるでしょう。 

> カーネル内にパーサーを入れることはLinusがいやがっていることもあって、みんな気にするので 
> もっと詳しく説明した方がよい。 
0x20（要素の区切り） と 0x0A （行の区切り）だけで機械的にパースできる TOMOYO の
表記法は、 0x0 （要素の区切り） と 0x0 0x0 （行の区切り）でパースするよりも
扱いやすく、安全です。 
「長さ＋文字列」でパースする方法もありますが、（パターン文字などを含む可能性が
あるため） 「文字列」の部分が正しい表記に従っているかのチェックはどのみち必要に
なります。 

TOMOYO の文字列処理関数の殆どは、文字列をパースする処理ではなく、文字列が正しいか
どうかを 検証するために必要とされています。 

> ログが見にくくなるだけだったら、こんな処理入れるな。 
ログが見にくくなるだけならこんな処理を入れないという選択肢もあるでしょうが、 
TOMOYO に関しては、ログ（を含めたすべての文字列）を欠損無く保持しておくために
不可欠なのです。 

712 ：login:Penguin：2009/01/12(月) 17:41:04 ID:fsX40d3O
>>703 
（略）

えーと、僕が言いたかったことが、あんまり伝わってない気がする。 
まず、レビューワはTOMOYOの仕様なんか知りません。なので、ほとんどの場合は
パッチディスクリプションとコードを見比べてレビューします。 

それで、パッチディスクリプションに説明がない場合は過去の議論に基づいて判断します。
多くの場合に。なので、このケースだと 

１．ディスクリプションがない 
２．過去にパーサーは嫌われていた 

−＞よし、Nack 

となるように、自分から仕向けているわけです。 
言いたかったのは説得するための理論武装はどこにあるんですか？ということです。 

パッチディスクリプションの書き方が悪いということ。

704のスレッド

704 ：login:Penguin：2009/01/12(月) 16:39:22 ID:SrCsF0ph
>>687 
> Ingo がftrace関係でファイル名を正規表現で指定できるようにしたい。って以前いっていたらから 
正規表現は昔の AppArmor が使っていたようですが、 TOMOYO で採用するつもりはありません。 
正規表現の問題点としては、 

（１）表記がプログラム毎にバラバラ（例えばシェルでは * は特別な意味を持つが . は
持たないのに対し、 sed では . は特殊な意味を持つ）であるため、利用者に対して
「事前に全ての正規表現を理解しておく」 
ことが必要 
（２）特別な意味を持つ文字を無効化するために何からの特別な文字（通常は \ でしょう）
を指定するという 実装だと、将来新しい意味を持たせたくなった場合に既存の文字列との
互換性が失われてしまうため、機能を 増やすために拡張することが不可能 
（３）（２）が発生するのを恐れて特別な意味を持たない文字まで \ を指定させるのは
ユーザにとって 読みにくいしパースする側としても無意味な処理 

というのがあります。 TOMOYO では特殊な文字は \ で始まるという実装であるため、 

（４）利用者は自分が知らないパターンに遭遇した時に初めて意味を調べればよいため、
利用者に対して 「事前に全ての正規表現を理解しておく」ことは不要 
（５）新しい機能を持たせたくなった場合は \ で始まる表記を定義することができるので、
拡張が容易 

というのがあります。 

>>690 
> security_task_free()はCredなくても事実上無意味だったはず。task struct ってRCUつかって、 
> スレッド死んだときとは違うタイミングで構造体破棄してるから、もともと使い道なんて無かった。 
メモリを解放するためのフックという意味ですので、スレッドが死んだときに
呼ばれなくても構いません。 
フックが存在していることが重要なのです。 

> tomoyo_domain_info にu32 を追加する方式では何が困るかが全然書いてないので返事のしようがないというのが感想。 
credentials により copy on write となったため、新しく -ENOMEM が発生する
可能性が増えました。 
credentials が無かった時代には存在しなかった error path を扱う必要が生じるため、
随所に if 文が必要になります。 

713 ：login:Penguin：2009/01/12(月) 17:45:52 ID:fsX40d3O
>>703 
>>704 

＞> カーネル内にパーサーを入れることはLinusがいやがっていることもあって、みんな気にするので 
＞> もっと詳しく説明した方がよい。 
＞0x20（要素の区切り） と 0x0A （行の区切り）だけで機械的にパースできる TOMOYO の表記法は、 
＞0x0 （要素の区切り） と 0x0 0x0 （行の区切り）でパースするよりも扱いやすく、安全です。 
＞「長さ＋文字列」でパースする方法もありますが、（パターン文字などを含む可能性があるため） 
＞「文字列」の部分が正しい表記に従っているかのチェックはどのみち必要になります。 

それは、記法にTOMOYOルールを追加するから、既存のルーチンの再利用ができなくなったと 
言っているんですよね。 

じゃあ、もっと話を根本にもっていって、TOMOYOルールいれんな。って言われたらどうします？
質問されてから、それに答えるだけってのは、マージの作戦として筋悪に見えてしまいます。 

>>704の説明は、完全にTOMOYO視点なので、カーネル開発者の視点に変換しないと説得力が 
でないんじゃないかな。 

ここでもTOMOYO視点ではなくカーネル開発者視点に立てという指摘。

714 ：login:Penguin ◆XkB4aFXBWg ：2009/01/12(月) 17:49:07 ID:PpBaufXM
>>710 
AppArmorのd_namespace_pathは、 
>In AppArmor, we are interested in pathnames relative to the namespace root. 
>This is the same as d_path() except for the root where the search ends. Add 
>a function for computing the namespace-relative path. 
とうことで、d_pathを拡張させたということでd_namespace_pathとしているようです。 

rootを超えたnsまでのpathという意味ではtomoyoも同じわけですが、 
d_namespace_pathにしてもtomoyoのrealpath(3)にしても、それぞれの実装以外では 
（おそらく）使われないですから、AppArmorやtomoyo(ccs)固有の名称に 
するのが無難ですね。（今さらですが） 

下記はTOMOYOプロジェクトのプロジェクトマネージャーの感想。(◆XkB4aFXBWgというのがついている発言はプロジェクトマネージャ)

715 ：login:Penguin ◆XkB4aFXBWg ：2009/01/12(月) 17:57:44 ID:PpBaufXM
>>701 
やりとりを見ながら、色々今さら（あるいは今ごろ）モードに入っています。 

> 過去の提案では security/tomoyo/ 以下だけの修正で済むようになっており、 
>TOMOYO を使わないカーネルのためにコードが大きくならないように配慮していました。 
これまでlkmlでレビューしてくれた人たちは↑のことをあまり意識してないような 
気がしてきましたが、気のせい？ 
ローカルならなんでも良いだろうとは言いませんが、コアのコードの修正と 
lsmのモジュールの修正（追加）では意味と影響範囲が違うわけで、 
そこが認識されていないため必要以上に厳しく見られているような。 


716 ：login:Penguin ◆XkB4aFXBWg ：2009/01/12(月) 18:19:30 ID:PpBaufXM
>>686 
>僕の感想では、たんに、ログが見にくくなるだけだったら、こんな処理入れるな。というのが共通認識だと思う 
（略）
>>703 
に書かれているように「ログを見やすくするため」ではないというのがまずあります。 
>crazy なファイル名に対してエンコードを施さないとどうしてsafeでなくなるのか説明されていない。 
>カーネル内にパーサーを入れることはLinusがいやがっていることもあって、みんな気にするので 
>もっと詳しく説明した方がよい。 
descriptionで以下の内容を強調したほうが良いと思いました。 
・tomoyoではポリシーの仕様として、0x20を含め全てのキャラクターを使えることを 
　目指した（SELinuxではそうではありません） 
・そのためにパス名の構成要素の正規化を行っている 


717 ：login:Penguin ◆XkB4aFXBWg ：2009/01/12(月) 18:29:33 ID:PpBaufXM
>>709 
（略）
>「メリットがなければコード追加しない」という価値観を前提に理論武装して説得するのがいいと思う。 
同感です。 

ただ、双方向リストを使うと、read lockをつけないといけないし、効率は落ちる、 
さらには将来tomoyoをフル機能にするときにネックになるということで、 
先生がすごく変えたくない気持ちも想像はつきます。 
ここは本当に悩ましいです。 

718 ：login:Penguin：2009/01/12(月) 18:56:00 ID:fsX40d3O
>>715 

＞> 過去の提案では security/tomoyo/ 以下だけの修正で済むようになっており、 
＞>TOMOYO を使わないカーネルのためにコードが大きくならないように配慮していました。 
＞これまでlkmlでレビューしてくれた人たちは↑のことをあまり意識してないような 
＞気がしてきましたが、気のせい？ 

えーと、改めて書くまでもないと思うけれども、基本ルールは 

・TOMOYOルールはtomoyoディレクトリにおけ 
・共通ルールは共通部におけ 

かと。 
んで、共通処理にできるっぽいのがsecurity/tomoyoにあったり、再利用できなさそう
なのが、共通部にあったりすると レビュー通らない。 
なので、レビューワーは一貫してると思うよ。 

TOMOYOの今の実装が悪いとはいわないが、説得のしかたが「だって、そう作っちゃったん
だもん」的な説得になっている ケースがあるのが、よくないと思う。 
TOMOYOのレビューの受け答えであっても、TOMOYOの事情を説明するのは、実は理由に
なってないんだよ。 
TOMOYOの仕様変えれば解決なのね。って相手は思うから。 

カーネル全体で見たときにどっちがよいか。って議論のメタレベルを１段階あげて、
大筋の方向性を合意した後テクニカルな議論に落としていくのが定石だと思う。 

議論の方向性、説得の仕方のいろはを教授している。さすがだ。

先に実装を作って、それを元に説得を始めるというのは典型的な悪いパターンなんだけど、企業発のオープンソースの場合、そーゆーのが往々にしてある。

そーゆーのにハマらないようにするために、実装をする前に、コミュニティに「〜という機能を追加したいんだけどさ」というRequest for Comments (RFC)みたいな文書を流すのが王道である。

だけど、先に作っちゃったんだから、仕様を変えてでも議論するしかない。

719 ：login:Penguin ◆XkB4aFXBWg ：2009/01/12(月) 19:07:54 ID:PpBaufXM
>>705 
>David Howells は絶対TOMOYOに良い方向にコメントしてくれるよう事前にネゴってあるの？ 
>で、なければ、いったんDavidは忘れてSerge攻略したほうがよくない？ 
ネゴっているというよりは、プライベートメールで調整した結果に基づいた 
パッチになっていて、tomoyo側（あるいはtomoyo単独の）希望や提案では 
ないのです。ただ、プライベートメールでそのことがLKMLには証跡として残っていません。 
スレッドで、Davidに呼びかけているのは、「そう、その通りなんだよ」的な 
一種裏付けを期待しています。 

Sergeは何が専門かわからないくらい色々なところに顔を出している 
エキスパートでは、ことこの部分についてはDavidや先生が理解しているほどには 
内容がよくわかっていないようであり、その意味でもcredentialの提案者である 
Davidの発言を待っていましたが、書いてくれないのでレスをつけて、 
Davidにその内容を裏付けして欲しいと待っているような状況です。 

722 ：login:Penguin：2009/01/12(月) 19:20:09 ID:fsX40d3O
ちょっと、繰り返しになるけれども、僕のレビューワーとしての視点でみるとTOMOYOは枝葉に 
こだわりを持ちすぎるのが悪い傾向かと思う。 

TOMOYOのキーコンセプトは「パス名ベースのセキュリティーモジュール」であり、
このコンセプトは みんなNackしていないので、いつマージされてもおかしくない状況。 
このキーコンセプトの範囲ではVFSだって変えれたんだし、このコンセプトの範囲では、
かなり強い立場で交渉できる状況。 

なのに、マージされないのはキーコンセプト以外に問題のあるコードが多い。 

・list1はTOMOYOのキーコンセプトなのか 
・d_realpath（）キーコンセプトなのか 
・今のパス名のTOMOYO記法はキーコンセプトなのか 

と聞かれたら全部NOでしょう。 
list1捨てても実装できるよ。今の記法を捨てても「パス名ベースのセキュリティ」は
出来るよ。ちょっと便利程度じゃ、 レビューワーから見ると再利用性を捨てるだけの
メリットじゃないから却下なんだよ。 
d_realpath()はまったくダメじゃないけど、TOMOYO以外が使えれるように汎用化しないと、
ちょっと論外っぽい。 

過去の発言みかえしてみると、TOMOYOチームが質問もらって、それに対してTOMOYOの事情を
説明したときに 相手が返事してないケースがかなりある。 
これはOKじゃなくて、消極的反対ってのは理解しといたほうがいい。 

一度仕様を、もっともっと削って、マージされてから改善する方を僕は押す。 
今のコードだと、僕がレビューワーならNackする。 

キーコンセプトは何か。それ以外のものはばっさり削除。

723 ：login:Penguin：2009/01/12(月) 19:33:24 ID:fsX40d3O
なぜ、段階的開発を押すかというと理由が２つあって 

１．（Andi Kleenの受け売りになるけど）パッチは論文を書くように書くべし。
というのがある。 
セキュリティの論文で、どっちが安全か議論しているペーパーで、ところで、slistを使うと 
効率がよくて・・なんて書いたら、どの指導教官でも絶対却下する。 
つまり、いまやっているのは、そういうこと。 
新しいコンセプトを世に問うているときに、違う枝葉を混ぜるのは筋悪 

２．一度いれて、ディストリに巻かれてからの方が、TOMOYOはこんなに多くのユーザに
使われているので コア部分を変えてでも改善する価値があるんだーー 
という論法が使えるようになる。これは大きい。 
レビューワーはコストとベネフィットの天秤でチェックしているので、コストが削れない
コスト（絶対必要な機能）なら ベネフィットをあげるしかない 

なぜ、段階的開発を取るかという理由を教授している。素晴らしい。

724 ：login:Penguin：2009/01/12(月) 19:43:48 ID:fsX40d3O
>>719 
＞>David Howells は絶対TOMOYOに良い方向にコメントしてくれるよう事前にネゴって
あるの？ 
＞>で、なければ、いったんDavidは忘れてSerge攻略したほうがよくない？ 
＞ネゴっているというよりは、プライベートメールで調整した結果に基づいた 
＞パッチになっていて、tomoyo側（あるいはtomoyo単独の）希望や提案では 
＞＞ないのです。ただ、プライベートメールでそのことがLKMLには証跡として残っていません。 
＞スレッドで、Davidに呼びかけているのは、「そう、その通りなんだよ」的な 
＞一種裏付けを期待しています。 

まず、人の好意を前提にした作戦は筋悪。 
Davidの立場からしたら、ここでTOMOYOに与すると自分が責任をとるぜと宣言する形に 
なってしまうから、相手を困らせる話のもっていきかた。 
自分自身の説得で、９割方説得できた後に、オレもそれでいいと思うよ。といわれる程度の支援 
しか期待しちゃダメだと思う 

＞Sergeは何が専門かわからないくらい色々なところに顔を出している 
＞エキスパートです。 

ははは、知ってます。 

＞しかし、ことこの部分についてはDavidや先生が理解しているほどには 
＞内容がよくわかっていないようであり、その意味でもcredentialの提案者である 
＞Davidの発言を待っていましたが、書いてくれないのでレスをつけて、 
＞Davidにその内容を裏付けして欲しいと待っているような状況です。 

これは筋悪。 
分かってもらえないのは説明の仕方が悪い。というのを議論の出発点にすべき。 
Sergeのような色々やってる人は全部細かくは見切れないからパッチ作る人が説明するのは
大前提になるよ。 

「誰々がこう言いました」は理由として弱すぎるので、TOMOYOに限らず、カーネル全体を
考えた上でも今の仕様がいいことを、理論的に説明できる必要がある。 
どうしてもダメなら、友情と好意にたよってもいいけど、それは最後の手段じゃないかな。 

TOMOYOのアンチパターンをこれでもかこれでもかと指摘するレビュアー。愛のこもった指摘がすごい。

725 ：login:Penguin ◆XkB4aFXBWg ：2009/01/12(月) 19:55:24 ID:PpBaufXM
>>724 
（略）

その意味では説明自体をDavidにふっている意識はなくて、必要な内容（説明）は 
書いてあって、Sergeがちゃんとわかってくれれば（笑）「なるほど」と 
思ってくれるはずなんです。 
（Davidが裏付けしてくれたらありがたいけど、必須ではなくて、頼り切っているわけでもなく） 

というふうにみた時、現状の説明ってやはり不足していると思われますか？ 

726 ：login:Penguin ◆XkB4aFXBWg ：2009/01/12(月) 20:31:01 ID:PpBaufXM
>>722 
（略）

プロジェクトを始めた頃は、文字通り夢にもメインラインのことは考えていませんでした。 
CELF, YLUGのショックを経て挑戦することにしたときも、本当にそれが可能とは 
思っていませんでした（思えませんでした）。でもそれが目指すべきことだと
教えてもらったので、挑戦を始めました。「こうすればマージされる」がわからないまま、 
投稿を繰り返していました。 

それがLSMのフックがマージされ、また昨日からのここのやりとりを見ていて、 
あらためて、「ああ、もう本当に手が届くところにきた。やっと来られたんだ」と 
思いました。変な言い方ですが、有限の努力と作業でなんとかなるところにこられたのだと 
感じました（今まではそうではなかったのです）。 

明日、中の人会議で話し合ってみますが、できることならここ、というか国内の 
方々にも見てもらって「これでいこう、というか逝け」と言われるパッチにして 
挑戦できたらと思います。 

随分遠くまで来ました〜という感慨深いコメントである。闇雲に手探り状態でここまで来たから、がんばったから。いや、がんばらなくてもいいから。相手を説得する方法を間違えていたわけで、多分、今の経験値でTOMOYOを再設計すればあっという間にマージされると思う。その経験は貴重だと思う。試行錯誤のなかで獲得したすごいことだと思う。

727 ：login:Penguin ◆XkB4aFXBWg ：2009/01/12(月) 21:44:25 ID:PpBaufXM
もし、普段LKMLを読んでいない人で、過去の議論を見たいという場合には、 
投稿ごとのリンクを以下にまとめてありますのでご利用ください。 
ttp://tomoyo.sourceforge.jp/wiki-e/?WhatIs#mainlining 

それぞれのリンクはLWN.netをさすようになっています。何故LWW.netかというと 
Linux公式ニュースサイトによる定点観測？のつもりで、 
それぞれの記事には議論のスレッドへのリンクがあるので、そこを開くと 
スレッドがたどれます。本当はLKMLへの投稿の他にfsdevなどでの議論も 
あったのですが（特に初期）、そちらはカバーしていません。 

http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#mainlining

が簡潔にまとめられている。

728 ：デムパゆんゆん：2009/01/12(月) 23:06:20 ID:TfRewdK6
>>701 
（略）
過去ログ引っ張り出して曖昧な記憶は無くしていく方がいいんでね？ 
引用リンクここにぺたぺた貼るとか 

>>722 
＞一度仕様を、もっともっと削って、マージされてから改善する方を僕は押す。 
＞今のコードだと、僕がレビューワーならNackする。 

ここまできてばっさり削ってコード変われば　また読み直しとかで 
メンテナする方からすればめんど〜なんぢゃねの？ 
相手からすりゃ　このまま特攻死（笑）　してくれた方がいいかも 
長い目で見るなら今のままの方がいい気もする 
ここでばっさり削除して仮に入ったとしても 
第三者からみれば印象悪いんでね？ 
SELinux陣と取引あったのかとか　いきすぎな慣例前例に結局根負けしたのかとか 
こういう所が　衰退の第一章だお　もう始まってそうな気も駿河　　んん　理想論かのぅ 
しかしLKMLは霞ヶ関みたいだお 
メンテナ＝官僚　LKML=省庁　パッチ投げる人＝政界に法案通してもらいたい政治ゴロ　地方議員 

ttp://jp.youtube.com/watch?v=HJoFM8ynyMQ 
革命戦士はヘルメットかぶり　一点突破的に突貫！　殲滅せよ！　殲滅せよ！ 


730 ：login:Penguin ◆XkB4aFXBWg ：2009/01/12(月) 23:47:55 ID:PpBaufXM
>>729 
・・・いや、帰ってくるので妙な見送り方しないでも大丈夫・・・ 

全部が全部、コメントを反映するわけにはいかないし、そうしたらそれは 
それでうまくいかないと思いますが、patch descriptionやコメントを 
見直すなどはやるべきだし、リストに関するコメントももらったご意見を参考に 
あらためて話し合ってみます（「あらためて」というのは、中では毎日のように 
こうした話し合いをしているからです） 


731 ：login:Penguin ◆XkB4aFXBWg ：2009/01/12(月) 23:59:52 ID:PpBaufXM
>>729 
パッチの15%は日本発というデータがあります。Linux Foundation Japanのサイトには 
tomoyoよりずっと早くからカーネル開発に関わってきた方々の講演の記録が残っており、 
メインライン化の取り組みの最初はそれらの情報を学ぶことでした。 
ttp://jp.linuxfoundation.org/?q=node/121 

そうした先達の助言は活かし、可能であればレビューしたもらったものを 
日本発の拡張として提案できれば、と思ったわけです。 


732 ：login:Penguin ◆XkB4aFXBWg ：2009/01/13(火) 00:08:17 ID:bjWNziJ3
>>728 
>引用リンクここにぺたぺた貼るとか 
可能なのですが、投稿している内容（範囲とアプローチ）、コメントしている相手 
（とコメントの経緯）などが違うので、その発言の部分「だけ」を抽出して 
並べてもちょっと難しいかもしれません。 

>ここまできてばっさり削ってコード変われば　また読み直しとかで 
>メンテナする方からすればめんど〜なんぢゃねの？ 
普通ならきっとそうなんですが、これまでの経験から言うと、 
「面倒」とか「何回も投稿するな」とかは言われないような気がします。 
「何度でも挑戦は受けて立つぜ」的な印象です。 

「効率的に収束する」提案の仕方ができないか考えているところです。 

相手を説得する時のアンチパターン（筋の悪い方法）と、筋のいいベストプラクティスをまとめるのは重要なことかと思う。TOMOYOが経験したアンチパターンとベストプラクティスは間違いなくバザール型オープンソースソフトウェア開発の方法論として重要な情報になる。コミュニティとのやりとりという方法論をまとめることは絶対無駄ではない。

自分の都合を押し付けない。コミュニティ全体に取って利益のあることを提案する。実装は変更することを躊躇しない。

そのような原理原則を学ぶ大変貴重な経験だったと思う。それをわれわれ第三者が疑似体験できるというのも情報の公開によってだ。オープンソースってすごいね。

733 ：login:Penguin：2009/01/13(火) 00:11:37 ID:g0j2pveV
>>725 

思う。 
まず、最初の 

>Serge, 
> 
>James is now reviewing TOMOYO Linux patch and he is caring about 
>your comment below. 
> 
>Serge E. Hallyn wrote: 
>> I don't like the 'in_exec' bit in the task_struct, but adding LSM hooks 
>> to let just TOMOYO mark whether you're in exec seems even uglier. 
> 
>Let me (once again) ask your comment on 'in_exec' approach 
>originally suggested by David Howells ( http://lkml.org/lkml/2008/10/2/127 ). 

というのは結構ひどくて、Sergeみたいな多忙な人だと以前の議論を全部覚えてるなんて
あるわけないから相手に手間をとらせているのがよくない話のもっていきかただとおもう。 

で、その数個あとの 

No. TOMOYO refuses to check read permission in security_dentry_open() 
if current->in_execve is set. 

で始まるメールはTOMOYOの説明でしかなくて、なんでカーネルアーキテクチャーの
観点から全般的にみてもこっちのほうがよいのかという説明になっていない。 
なので、「僕のために変更する、は悪いパッチ。みんなのために変更する、
は良いパッチ」の原則にしたがい否定的な反応をいただくことになる。 

734 ：login:Penguin：2009/01/13(火) 00:14:19 ID:g0j2pveV
>>711 
ここは、考え直していて、ちょっと意見が変わった。 
そもそもrealpath()ライクな関数をつくることが目的じゃなく、TOMOYO依存部と
共通部を切り離すことが目的なんだから関数インターフェースを１から考え直したら
どうだろう？ 
realpath()にこだわっている限り、TOMOYO依存部と共通部がうまく切り離せないの
かもしれない。 

736 ：login:Penguin：2009/01/13(火) 00:24:09 ID:g0j2pveV
あと、あれです。 

レビューワーは大なり小なり、好き嫌いがあるので、納得できない指摘をうけ
ることも多々あるけど、 絶対譲れないキーコンセプト以外は言うこと聞いた方
がいいです。

そうでないと、TOMOYOをレビューしてあげたら、個人攻撃くらうは指摘は無視
されるわで散々だったよ。って思い出が残る。
そうすると長期的に見て、味方がどんどん減っていく。

レビューはおもてなしだよ。 


過去のメールを読み返して、議論の最後が相手の"makes sense"とか"looks
good"とか"agreed"とかいう単語で 終わってないのは議論が失敗しているので、
成功しているときと失敗している時との差は読み返して確認してみるのが、
オススメ 

レビューはおもてなし。

過去メールを読み返す。議論が成功しているか失敗しているか。それを確認する。

737 ：login:Penguin：2009/01/13(火) 00:32:06 ID:g0j2pveV

あとは議論のテクニックの問題として、「私は正しい。なぜなら・・」というのは
良くないスタイル。 
最終的に自分が正しかったとしても、議論に負けた方がいやな気持ちになるので
おもてなしの原則に反する。 
結構TOMOYOチームは多用してるので気になった。 

最初に、自分が考えるとりえる選択肢を２，３個かいて、それぞれのPros, Consを
説明して、この中で検討した結果ｘｘ番がいいという結論に達した。的ないいかたを
したほうが、レビューワが前提があっているかどうかとか
そういう観点でジャッジメントできるし、一緒に考えよう的な方向に話を誘導しやすくて
オススメ 

他の選択肢がないと、なんかコードが汚くて気にいらないから、他の選択肢考えてみて。
というコメントのつきかたを招きやすいと思う 

おもてなしの原則に反する例。なるほど。よい例も示している。すごいな。

738 ：login:Penguin：2009/01/13(火) 00:37:08 ID:g0j2pveV
あとは、あれかパーサーがtomoyoディレクトリにあると、延々と文句がきそう
なので、タッグを組む相手を頑張ってさがして、 ２人以上つかってるから、
libにいれるよん。というリアクションがとれるよう、パートナー選びをもっと
真剣にやるべきと 思った。

で、パートナー選びを考えると、今のＴＯＭＯＹＯ記法は特殊すぎるので、記
法の変更もある程度は覚悟したほうがよいと思う。

仕様の変更もいとわない。

744 ：login:Penguin ◆XkB4aFXBWg ：2009/01/13(火) 07:43:50 ID:bjWNziJ3
みなさん、ありがとうございます。 
どんな人がどのくらいきているのかわかりませんが、 
いつのまにか思っていたより多くの人たちが気にして、応援してくれているのだと感じます 
一種、元気玉を分けてもらっている気がします 
自分には夢があって、いつか本当にマージができたら、ここで 
伝説の「ありがとう、おまいら」を言ってみたいです 
まだ先は長いですが、がんばります 
thanks in advanceです 

マージまでもすこしだ。

745 ：login:Penguin ◆XkB4aFXBWg ：2009/01/13(火) 16:53:25 ID:KdRVIBbl
とりあえずlist1を双方リストに置き換えられないか検証（本当にそれで動くか確認） 
してみることになりました。もし可能な場合は、realpath(3)は解消し、 
Alへの確認もいらなくなるようです。 

また、Davidとのやりとりは、実はSergeもccされていたことが判明し、(; ;) 
関係者に議論の証跡をlkmlでさらしてよいか（Sergeを含めて）関係者に聞いています。 

ゆずれるところはゆずって、マージを目指します。 


746 ：login:Penguin ◆XkB4aFXBWg ：2009/01/13(火) 18:43:30 ID:QtV6ZzdK
久しぶりにLinux Weather Forecastを覗いてみたら、tomoyoのところが更新されていました。 
ttp://www.linuxfoundation.org/en/Linux_Weather_Forecast/security 

TOMOYO Linux 
TOMOYO Linux is a mandatory access control framework similar to
AppArmor.  Like AppArmor, it has been criticized for its use of
pathnames and (to some) simplistic approach to security.

Forecast: 
TOMOYO Linux has only recently surfaced on the wider mailing lists;
its reception has not been entirely friendly. This project's
developers have some work to do if they are (1) to get past the same
obstacles which have slowed AppArmor, and (2) show that their project
is sufficiently different from AppArmor to merit inclusion as yet
another security framework.

とここまではおそらくこれまでと同じですが、その後に 

The merging of the pathname-based security module hooks for 2.6.29 has
helped this cause significantly, though; a 2.6.30 or 2.6.31 merge is
not entirely out of the question.
（しかし、2.6.29でpathname-based用のフックが追加されたので状況は大幅に変わった。 
2.6.30, 31でのマージは全くあり得ないことではなくなった） 

が追加されています。多分書いているのはJonathanですがびっくりです。 

747 ：login:Penguin ◆XkB4aFXBWg ：2009/01/13(火) 18:51:15 ID:QtV6ZzdK
>>745 
>もし可能な場合は、realpath(3)は解消し、 
>Alへの確認もいらなくなるようです。 
について、「それは違う」と先生に突っ込まれました。procのselfのところが 
いらなくなるだけで、上の内容は間違っているようです。 

でもこのあたりは何回聞いてもややこしくてよくわかりません・・・。 
ちゃんと説明したものがないのが悪いんです。（笑） 

748 ：login:Penguin：2009/01/13(火) 19:04:13 ID:acMdqThM
james_morris: Security changes in the 2.6.28 kernel 
ttp://james-morris.livejournal.com/37583.html 
@ 2009-01-06 20:55:00 
Also noteworthy is the merge of the pathname security hooks for LSM, 
which should pave the way for TOMOYO and AppArmor in 2.6.30, 
subject to the general patch submission review process. TOMOYO is 
only a couple of acks from approval, has been baking in -mm, and is 
pretty much self-contained. It may even appear in 2.6.29 if the 
merge window is open for features long enough. 


749 ：login:Penguin ◆XkB4aFXBWg ：2009/01/13(火) 19:36:07 ID:QtV6ZzdK
>>748 
thanks :-) 

Jonathan Corbet氏、ある日のブログから 
ttp://linux-foundation.org/weblogs/lwf/2009/01/11/looking-forward-to-2629/ 

One small, quiet piece of code which went in was a new set of security
module hooks which enable the addition of pathname-based mandatory
access control mechanisms.  This was an important prerequisite for
security modules like AppArmor and TOMOYO Linux, which may finally be
getting close to inclusion into the mainline.

あらためて、lsmフック追加の「小さなコード」の価値を感じます。 


757 ：login:Penguin ◆XkB4aFXBWg ：2009/01/14(水) 18:12:32 ID:w5+hnGvV
さきほど投稿した「とりあえず（マージされるまでは :-）list1やめます」的返信です。 

James Morris wrote: 
> > By ommiting pointer to previous element, the reader becomes read lock free, 
> > which is good thing for implementing "write once read many" list. 
> 
> This has a technical ack from Paul, but what about Linus' long-standing 
> objection to singly-linked lists in the kernel? I'm sure this has been 
> discussed re. your patches, but I can't find a reference. 
> 
OK, for reviewers' ease, I purged list1 for now. 

Next posting (#15) will use standard doubly linked list with
rw_semaphore.

Thanks. 

758 ：login:Penguin ◆XkB4aFXBWg ：2009/01/14(水) 18:17:14 ID:w5+hnGvV
同じく/proc/selfも。sad thingの部分が泣かせます。;-) 

James Morris wrote: 
> > (3) /proc/PID/ is represented as /proc/self/ if PID equals current->tgid. 
> 
> This needs an ack from Al and/or Christoph. 
> 

It is a sad thing that I cannot use /proc/self/ (which is the only
part where a pathname based access control can prevent current process
from accessing other process's information), but I purged d_realpath()
for now.

Next posting (#15) will embed AppArmor's d_namespace_path()-like
function into TOMOYO's code.

対応の方針が決まっても、3人が納得できるような文案を考えるのが大変です。;-) 
Sergeについてはメールでやりとりしていてお返事待ちですが、Stephenなども 
チェックしているのでそろそろあきらめてくれないかなと (^O^; 

761 ：login:Penguin：2009/01/14(水) 19:52:07 ID:5NKh0/Wc
結局正規表現関数群はどうしちゃうんだろ 

764 ：login:Penguin ◆XkB4aFXBWg ：2009/01/15(木) 12:01:27 ID:cWUoCFDQ
>>761 
>結局正規表現関数群はどうしちゃうんだろ 
>>687 のことですか？ 

昨日の中での話し合いでは、既存リストの利用、selfをあきらめる、の他に 
descriptionとcommentの見直しを行うことを決めましたが、LCAもあり、
それらの反映結果を#15として投稿するのは1月末になりそうです。
2.6.29のマージウィンドウが閉じ、LKMLで新たにstackableの議論が始まるなど、
場は動いています。作戦としては とりあえずLKML指摘に対応したものを早く
投稿するのを優先という考え方です。 

765 ：login:Penguin ◆XkB4aFXBWg ：2009/01/15(木) 12:09:54 ID:cWUoCFDQ
>>761 
パーサについて自分の考えを書きます。（今日は先生は体調不良でお休みです） 

「カーネル内パーサってどうよ？」というコメントは過去確かにありましたし、
好ましくないのは事実と思います。 
ただ、tomoyoについて「パーサ」と呼ばれている部分は、パスをそのまま文字列
として格納しているというのが実際で、汎用の文字列操作ライブラリではなく、
むしろDBに近いものと思います 
（それをパーサと呼ぶと言われればそうかもしれませんが）。 

linux/lib以下に置くようなものには遠いですし、tomoyoとして必要な機能を考えると 
バイナリ形式に変換してもうれしいことはないというのが先生の考えだと思います。 

769 ：login:Penguin：2009/01/16(金) 02:13:52 ID:T2fQPja9
>>765 
カーネル的にはパーサー以外の何者でもないんだよね。 
これが本当にstrcpy()して格納してるだけなら文句は絶対こないと思う。 


771 ：login:Penguin ◆XkB4aFXBWg ：2009/01/16(金) 07:26:08 ID:1W9JShIi
>>769 
多分、文字列で格納している時点でパーサなんだと思います。(; ;) 
でもtomoyoの場合というかtomoyoの使い方はカーネル内であっても 
許容される範囲ではないかと思います。逆に言えば、バイナリで保存して 
インデックスをつけても、誰にとってもうれしいことはないように思います。 


772 ：login:Penguin：2009/01/16(金) 21:21:00 ID:T2fQPja9
>>771 
バイナリで保存するのに意味がないというのはそのとおりだと思う。 
これはレビューワーがいやがることを避けるのがNAKされない為に重要。という
半分テクニックの話だとも思う。 

でも、メンテナーが過去の経験として文字列処理はつまらんバグやバッファオーバーフローを
産みやすく、過去何度もセキュリティ勧告をくらっていやな思いをした経験から「ちゃんと
した理由がなきゃいやだ」と思っているという背景は理解するべきで、
「だって僕はいるんだもん」的な説得は相手の心に響かない。
ので、事前に作戦考えておいたほうがいい。とは思う。 

たとえば、パス名ベースセキュリティのように、カンファレンス等を通じて「コンセプト」を
レビューしてもらって 承認を受けるというのも１つの手だし、誰かと組んで共通ライブラリに
してもいいし、 何か他の手段でベネフィットを上げれればいいんだという認識。
所詮コスト vs ベネフィット議論なので。 

それか、もっと行数を縮めて、ほかのにまぎれて入れてしまうという寝技もアリはアリ。 

今は説明ない、コードは目立つ、必然性がよく分からないの３点セットなのがいけないと
思うのですよ。 


773 ：login:Penguin：2009/01/16(金) 21:27:21 ID:T2fQPja9
僕の理解では、TOMOYOの独自記法のメリットがコンセンサスを得られているとは
いいがたいと思ってるのよ。 
少なくとも独自記法は確実に共有コードが減るというデメリットがある。なので、
それを上回るメリットがあることの説明は必要と思う。 


774 ：login:Penguin：2009/01/16(金) 21:29:30 ID:T2fQPja9
「パーサーだったら、絶対だめ」的な過激な人は一人もいないという認識なので、 
要は、メリット＞デメリット を説得できるか、で、どの観点から攻めるのかを戦略決めようね。と 

戦術あっての戦略戦略あっての戦術なのだけど、TOMOYOには戦略がない。

777 ：login:Penguin ◆XkB4aFXBWg ：2009/01/16(金) 22:57:22 ID:1W9JShIi
熊猫先生とLiveCDの中の人は来週au confのため、次に3名が揃うのは1/26になりました。 
戻ってからも#15の準備や他の作業でしばらくあまりレスがつけられないかもしれません。 

コードの修正についてはこれまでそうしてきたように最終的には熊猫先生が判断します。 
もしかしたら、いただいた提案やご意見と同じにならないこともあるかもしれません、でも 
できるだけ納得して、思うようにやってもらい、そして良い結果を出して欲しいと願っています。 
tomoyoのことを一番理解しているのは先生だし、先生がいなければtomoyoも存在していないのです。 

対応しても、しなくても、ここでもらった意見は3名とも深く感謝しています。 
気にしてもらえることを本当にうれしく思っています。 
でふぁ 


778 ：login:Penguin ◆XkB4aFXBWg ：2009/01/16(金) 23:40:42 ID:1W9JShIi
>>777 
　　 ／￣　￣＼ 
　／　　 _ノ　　＼　　・・・何が言いたい？ （何げに777踏んでるし） 
　|　　　 （ ●）（●）　　　　　　　 　　 　 　 ＿＿＿_ 
.　|　Ｕ　　 （__人__）　　　　　　　　 　　／　　 　 　＼ 
　 |　　　Ｕ　｀ ⌒´|　　　　　　　 　　　／─　 　 ─　　　＼ 
.　 |　Ｕ　　　　　　}　　＼　　　 　　／ （●）　（●） 　　　＼ 　　 
.　 ヽ　　　　　 　 } 　　　 ＼　 　 　|　 　（__人__）　　　　 　 |　書いてて自分でもわからなかったお　 
　　 ヽ　　　　　ノ　　　 　 　＼　　 ＼　　 ｀ ⌒´ 　　　　　_／ 　　 
　　　/　　　 く.　＼　　　　　　＼　 ノ　　　　　　　　　　 ＼ 
　　　|　　　　 ＼ 　＼　　　　(⌒二　　　 　　　　　　　　 　| 
　 　 |　　　　|ヽ、二⌒)、　　　　 　＼　　　　　　　 　｜ 　| 



779 ：login:Penguin ◆XkB4aFXBWg ：2009/01/16(金) 23:46:12 ID:1W9JShIi
　　 　 　 ＿＿＿_ 
　　　　／　　 　 　＼ 
　　 ／　　─　 　 ─ ＼ 
　／ 　　 ,（●）　（●）､＼ 　やるだけやってダメなら本能 
　|　 　　 　 （__人__）　| 
　＼　　　　 ｀ ⌒´　　 ／ 
,,.....イ.ヽヽ、___ ーーノﾞ-､. 
:　 　| 　';　＼_____ ノ.| ヽ　i 
　 　 |　　＼/ﾞ（__)＼,| 　i　| 
　 　 ＞　　 ヽ. ハ　 | 　 |｜ 
　　　　　　　　　　 　 -‐ '´￣￣｀ヽ､ 
　　 　 　 　 　 　 ／　／" ｀ヽ ヽ　　＼ 
　　　　　　　　　//, '/　　　　 ヽﾊ 　､　ヽ　　　　　　 
　　　　　　　　 〃 {_{ノ　　　 ｀ヽﾘ| ｌ │ i| 
　　　　　　　　 ﾚ!小ｌ●　　　 ● 从　|、i|　　動物か？ 
　　　　　　　 　 ヽ|l⊃　､_,､_,　⊂⊃　|ﾉ│　　 
　 　 　 　 /⌒ヽ__|ﾍ　　 ゝ._）　 　j /⌒i !　　 
　　　　　　＼ /:::::|　l＞,､ __,　イァ/　 /│　　 
　　　　　 　 /:::::/|　|　ヾ:::|三/::{ﾍ､__∧ | 
　　　　　　　｀ヽ< |　|　　ヾ∨:::/ヾ:::彡'　| 

冗談はともかく最近ここに入り浸っていて他のことをできてなかったので（本当）、 
au confが終わるまでしばらくひきこもります。 


780 ：login:Penguin：2009/01/16(金) 23:59:28 ID:T2fQPja9
>>777 
うーん、コードの修正するしない、に議論が小さくなっているのは、ちょっと残念。 
どうも、通じてない気がするな。僕ならこう書くというのを出そう。 

まず、論文であるので、最初にアブストラクトを書く。 

パス名ベースのセキュリティモジュールでは、カーネルに対して対象オブジェクトを
パス名で指定する。 
このパス名はファイルそのもののパスでもよいが現実的には、もっと柔軟な指定方法が
必要である。 
（あなたのシステムで/etc/以下に何個ファイルがあるかを考えてみたら、１つ１つ指定する
気はすぐに失せるだろう） 
そう、我々は柔軟でパワフルで、「かつ」 誤解しにくいパス名の記法が必要である。 

・・・などのように書いて、regularなexpression は必須なのはあきらかだから、
どういうexpressionがいいかを議論するよん。的な出だしにする。 
んで、次に選択肢を３つ並べる 

１） shell glob style expression 
２） POSIX regular expression (UNIX style regular expression) 
３） 独自記法 

＃ １）と２）が普通の人が最初に思いつく選択肢なので必ずのせる。それであとで、
＃１と２を論破して３のTOMOYO独自記法サイコー。 
＃ という結論に誘導する事を目的にする 

AppArmerは（２）を選択しており、一見これはよい選択肢に見える。しかしこれには
重大な見落としがある。 
POSIX regular expressionのメタキャラクタの多くはファイルシステムで使用可能な
文字であり、エンドユーザは間違った正規表現を書きやすい。 
また、linuxでは「習慣として」英数字以外のファイルがほとんど存在しないため、
間違った正規表現でも動いてしまうのが問題だ。 
これは攻撃者が特殊なファイル名のファイルを作成したときに、初めて間違いが露見する事に
なる 

＃ここで具体例を２，３個いれる 

（つづく） 

781 ：login:Penguin：2009/01/17(土) 00:05:30 ID:BLqmOvB5
これは誰が悪いのだろうか？ 
TOMOYOのバグか？明らかに違う。TOMOYOは指定された通りに動いている。 
では、エンドユーザか？AppArmer関係者はYesと答えるだろう。 

しかし、「我々は」そう思わない。 

ユーザが正しく使えないセキュリティモジュールなど、なんのセキュリティ的な価値が
あるだろう。 
我々には、誤解しにくい、明瞭なシンタックスをもった、POSX regular expressionと
同等にパワフルな記法が必要だ。 

よって、我々は以下の記法を提案する 

＃ここでTOMOYO記法の紹介にうつる 
＃たぶん、いまのTOMOYO記法はメタキャラクタが、ちょっと多すぎるので論文の都合上
＃もうちょっとダイエットされていると 
＃ストーリーが通りやすい。。。 

この記法はシンプルでパワフルで、そして「セキュア」だ。 


と書いて論文をしめる。 
相手はTOMOYOの識者ではなく、セキュリティの識者なので、アプローチはかならず
「セキュア」という単語を含める。 

プロジェクトで予算を獲得するためにエロい人と話をするときは「TOMOYOが分かればあなたの
疑問は解決します」とはいわずに、粛々とお金の話をすると思う。それと同じ。
相手によって、会話のキーポイントを変える。 


782 ：login:Penguin：2009/01/17(土) 00:11:06 ID:BLqmOvB5
以上、僕がパッチディスクリプションを書くなら。という仮定で、書いてみたけど、
TOMOYOルールだから、という単語は使わずに、セキュリティを考えていったら、
今の記法になっちゃった。というストーリーが作れる。というのは分かって 
もらえたと思う。 

こうやって、理由が書いてあるとレビュアーは "It's no sense!!" とはいいにくいので、
承認するか、建設的な代替案を出すかの二択に精神的に追い込まれる。 

・・・・ふだんレビューワーの僕がいってるんだぜい？ 

もちろん、本当に、建設的な代替案がでてきちゃったら、ちゃんと対応しないとダメですよ。 
もう出荷しちゃったから変えられねーー、とかレビュー拒否かと思わんばかりの発言して
反発くらったAppArverの二の舞にならないように。 

784 ：login:Penguin：2009/01/17(土) 00:27:44 ID:BLqmOvB5
で、話をもどすと、これは相手にこちらの思考をトレースできるようにして、
ベネフィットを上げる作戦ね。 

最初に実装つくって、口説き方を考えるよりも、口説き方を考えた後で、 
それにあわせて実装修正したほうが、考える幅を、広くとることが出来るんだよね。 

他にもいろいろ作戦はあると思うけども、ギーク口説くのも、女を口説くのも、
たいして違いはなくて、相手に会わせてアプローチ変えるのキモだと思うのです。 

たぶん、TOMOYOの方々は僕よりもセキュリティに数倍詳しいので、もっといい口説き文句が
考えられるはず。 

論文を書くように書く。素敵だ。

口説く方法を相手に合わせてアプローチを変える。

783 ：デムパゆんゆん：2009/01/17(土) 00:24:03 ID:Z3OQs+LA
　　ﾚﾋﾞｭｱｰ 　　 　　　　　∧＿∧ 
　　 ＿ノ⌒＼＿ノ　 　　 < ；｀Д´>　アイゴ！！アイゴォォ！ 
　／ 　∧∧　　 　ﾋﾟｼｯΣ（=====） 
(＼　／ 不＼　彡　　　　 ( ⌒)っ)｡'｡ﾟ_･ﾟ 
　< （　｀ハ´ .）　／￣￣￣'し￣￣／＼ 
　　＼　　⊂ ）　￣￣￣￣| |￣￣￣￣ 
　　／　　　　＼　　　　　　| | 
　　し￣￣￣＼)　　 　 .／　＼ 
TOMOYOのくせにﾅﾏｲｷｱﾙ！ こうですね 

785 ：login:Penguin：2009/01/17(土) 00:28:31 ID:BLqmOvB5
>>783 
ぜんぜん違げーwwwwww 

アスキーアートwww

TOMOYO Linuxに学ぶ説得術、その２

なぜか、アスキーアートで切れてしまったので、続きを。

技術的な議論はほぼ収束という感じか。

そして15回目のLKMLへの投稿というメッセージ。

822 ：login:Penguin ◆XkB4aFXBWg ：2009/02/05(木) 23:52:49 ID:EiMYLrjN
昨日、#14で未解決になっていたSergeの問いかけに答えたところ、 
納得してくれたかどうかはわかりませんが、新たなつっこみは 
ありませんでした。 

場の空気が変わると状況が難しくなる可能性があり、またタイミングが 
遅れると2.6.30のマージウィンドウに間に合わないので、 
ここでの議論が途中ですが、本日中の人会議を行い、#15を投稿しました。 
descriptionの詳細化など、最低限の対応はできています。 

今度こそ！ (^O^)/ オー 

がんがれ〜〜

825 ：login:Penguin：2009/02/07(土) 08:17:48 ID:wkPuQF66
　　 ／￣￣＼ 
　／　　 _ノ　　＼　　・・・どこが「出つくした」んだよ 
　|　　　 （ ●）（●）　　　　　　　 　　 　 　 ＿＿＿_ 
.　|　Ｕ　　 （__人__）　　　　　　　　 　　／　　 　 　＼ 　　さて、意見も出つくした 
　 |　　　Ｕ　｀ ⌒´|　　　　　　　 　　　／─　 　 ─　　　＼ 　　ということで 
.　 |　Ｕ　　　　　　}　　＼　　　 　　／ （●）　（●） 　　　＼　　ジェームズ　マージ　たのむ 
.　 ヽ　　　　　 　 } 　　　 ＼　 　 　|　 　（__人__）　　　 　 　|　　 
　　 ヽ　　　　　ノ　　　 　 　＼　　 ＼　　 ｀ ⌒´ 　　　　　_／ 　　 
　　　/　　　 く.　＼　　　　　　＼　 ノ　　　　　　　　　　 ＼ 
　　　|　　　　 ＼ 　＼　　　　(⌒二　　　 　　　　　　　　 　| 
　 　 |　　　　|ヽ、二⌒)、　　　　 　＼　　　　　　　 　｜ 　| 

そしてJamesのツリーに

831 ：login:Penguin ◆XkB4aFXBWg ：2009/02/12(木) 14:39:38 ID:arb85fbR
Jamesのツリーにはいりますた。 

832 ：login:Penguin：2009/02/12(木) 14:49:50 ID:ZU9msm4p
ここすな。 
ttp://git.kernel.org/?p=linux/kernel/git/jmorris/security-testing-2.6.git;a=summary 

おめっとさん。 

833 ：login:Penguin ◆XkB4aFXBWg ：2009/02/12(木) 14:52:06 ID:arb85fbR
ありがとう！ 

でも、正直、今この段階でどれだけ喜んでいいのかわからないので困っています（笑） 

834 ：login:Penguin ◆XkB4aFXBWg ：2009/02/12(木) 15:04:21 ID:arb85fbR
だめだ。 
だんだん、うれしくなってきた。(T_T) 

835 ：login:Penguin ◆XkB4aFXBWg ：2009/02/12(木) 15:13:36 ID:arb85fbR
ttp://lists.sourceforge.jp/mailman/archives/jsosug-users/2009-February/000068.html 

836 ：login:Penguin ◆XkB4aFXBWg ：2009/02/12(木) 15:35:18 ID:arb85fbR
>>833 
>でも、正直、今この段階でどれだけ喜んでいいのかわからないので困っています（笑） 

本格的に来るとアレだけど、少しくらいなら来てもいいんじゃないか？（違う？） 

そしてLinus' treeにマージされた。

992 ：login:Penguin：2009/04/08(水) 23:08:09 ID:tDtF8ZyH
ありがとうございます。ここまでをふりかえると 
確かに苦労もしたし、悩んだりもしましたが、 
それ以上に運にめぐまれていたし、 
直接間接いろいろな人に助けられたと思います。 
そうした全てを無駄にしないためにも今まで以上に 
がんばります。 

最後まで読んでくれてありがとう。

匿名レビュアーが指摘していることは、どれをとっても、交渉ごとのイロハだ。Linuxコミュニティ特有のことといううよりも対人関係において、相手と妥協点を見つけるということに関する普遍的な方法論をTOMOYO Linuxという事案を例に懇切丁寧に説明している。交渉ごとのプロフェッショナルという得がたい味方をTOMOYO Linuxははからずも得たわけである。オープンソースプロジェクトでなければ、このようなプロセスを第三者である我々はうかがい知る事ができなかった。この２chのスレの過去ログを読むことが出来、時間を越えて疑似体験できるというのは、オープンソースプロジェクトならではである。

昨日のTOMOYO Linuxの勉強会の小崎さんのプレゼンで紹介があったので、２chの過去ログを読んでみたが想像を越えるやりとりがここにはあった。小崎さんをはじめとするTOMOYOの外の人の協力なしでは決してメインライン化は達成できなかったのではないだろうか。イノベーションは会社の外で起こる。Innovation Happens Elsewhere (IHE)である。

Linuxはコミュニティが作っていて、それは誰か一つの企業のものではないということを改めて実感した。Linuxはコミュニティのものだ。そして原田さんたちは、それを深く理解した。

おめでとうTOMOYO Linux。ありがとうTOMOYO Linux。

ツイートする

Permalink | コメント(0) | トラックバック(0)