【めざせ】TOMOYO Linux 0.0.2 【本家入り】

**login:Penguin** ◆XkB4aFXBWg · 2008/06/03(火) 23:07:21

使いこなせて安全な強制アクセス制御(MAC)実装、TOMOYO Linuxのスレッドです。

TOMOYO Linux プロジェクト
ttp://tomoyo.sourceforge.jp/
TOMOYO Linux の世界
ttp://tomoyo.sourceforge.jp/wiki/?WorldOfTomoyoLinux
TOMOYO QandA
ttp://tomoyo.sourceforge.jp/wiki/?QandA
はてなキーワード TOMOYO Linux
ttp://d.hatena.ne.jp/keyword/TOMOYO%20Linux
TOMOYO メインライン提案まとめ
ttp://elinux.org/TomoyoLinux#Mainline
過去スレ
TOMOYO Linux ttp://pc11.2ch.net/test/read.cgi/linux/1152257294/
まとめ ttp://tomoyo.sourceforge.jp/wiki/?TomoyoIta1

**login:Penguin** ◆XkB4aFXBWg · 2008/12/12(金) 13:00:18

>>618
>見あたらないお？？

「探検隊」の記事は、12/13締め切りですが、それが発売されるのは
来月1/18で、「１月号」ではなくて「２月号」でした。(_ _; 　スマソ
ちなみに、原稿提出してから「ゲラ」というのが送られてきて、それを
１、２往復して記事が確定します。

**login:Penguin** ◆XkB4aFXBWg · 2008/12/12(金) 21:03:01

Alが返事をしてくれないので、今日LKMLにこんな恐ろしいメッセージを投稿しています。(=_=; ブルブル

Subject: Re: [patch 04/11] vfs: introduce new LSM hooks where vfsmount is available.
Date: Fri, 12 Dec 2008 10:59:39 +0900
To: Al Viro

Al, please give us Acked-by response.
(patch refreshed for mmotm-2008-12-11-15-20).

Regards,

---
Subject: vfs: introduce new LSM hooks where vfsmount is available.
（以下省略）

**login:Penguin** ◆XkB4aFXBWg · 2008/12/12(金) 21:32:00

自分は昨日、一昨日と休みをとっていましたが、その間にJamesがAppArmorの関係者に
「TOMOYOからこんなパッチがでてるけど、AppArmor的にどうよ？」的メールが
送られていました。また、Jamesは「Alのackが必要だね」と大変わかりきったことを書いていますた。

たまにここで報告していますが、そうした私信（主に助言、アドバイス）は多くて、全てが
オープンで公開された議論というわけでもないです。tomoyo以外でもそうなんじゃないかと思います。

**デムパゆんゆん** · 2008/12/12(金) 22:41:30

>>619
ラ～ジャ～

ｱﾙﾋﾞﾉとはもう痴話げんかだなｗ
あなたっていつもそう　都合悪くなったらすぐ居なくなる
なんであたしばかりなのよ　と、そろそろとどめの泣き落とし降臨ｷﾎﾞﾝﾇ
しかしselinux陣営は中国共産党一党独裁体制みたい
反体制は粛正！　アカい血潮漲らせ敵を殲滅せよ！　進め！　進め！　みたいな感じか
ジェームスおぢちゃんはそういう所気にしているのかしらん
対抗馬　おながいしまつ　出てきてくだしあ（泣　みたいな
知代ちゃんも来年は負けずに　我々は米帝の許されざる横暴に断固として戦う！
ここに結集した同士と共にselinux陣営に革命的殲滅を行う事を声明する！　とか。
決戦に備え年末は有馬温泉で決起集会であります　いい湯だお。

**login:Penguin** · 2008/12/12(金) 22:52:00

>>622
ラベルベースにはラベルベースにしかできないことが、パス名ベースにはパス名ベースにしかできないことがあります。
ttp://sourceforge.jp/projects/tomoyo/docs/lfj2008-bof.pdf
現状の LSM は排他的ですが、殲滅のために争うのではなく、共存のための対話が必要です。

**デムパゆんゆん** · 2008/12/12(金) 23:48:37

>>623
第３者の立場から見てると共存目指すと言うよりLSMの中で内ゲバしてるみたいだお
アルビノが要求している事　満たしてるのか　ただのいやがらせなのか
それとも知代ちゃん陣営が要求に届いてないのか　とか
本人になんで答えてくれないと聞くよりも
まだ気に入らない所あるのか　やるべき事あるのか
まわりにいる人間に交渉してもらえないかとか言った方がいいような気もする
やってる感じもするけどもう少しアルビノに近い人に交渉するとか
個人的にアルビノは東洋人嫌いのような感じもするが
今のままでは平行線のママであります　ママァ
共存と対話目指すなら福田元総理がやったような全方位土下座外交であります
中間管理職は怒ったらいかん　怒ったらいかん　ていうくらい大変だお

**login:Penguin** ◆XkB4aFXBWg · 2008/12/16(火) 07:34:09

信頼すべき情報筋によると、LKMLでしばらく発言がなく、休暇中？と
思われていたAl Viro氏は昨日久々にLKML上で発言したようです。
（外国の人は結構こうして数週間単位でどこかに行くことが珍しくありま温泉）

**login:Penguin** · 2008/12/17(水) 13:52:08

>>625
返事来ましたな。
queueがつまってないことを祈りましょうか。

**login:Penguin** ◆XkB4aFXBWg · 2008/12/17(水) 13:52:21

待ってた返事ではないけれど、とにかくAl Viroから返事が北ー。

From: Al Viro
Date: 2008/12/17
Subject: Re: [PATCH] introduce new LSM hooks where vfsmount is available.
To: Kentaro Takeda

On Wed, Dec 17, 2008 at 01:24:15PM +0900, Kentaro Takeda wrote:
> Al, would you respond to this patch?
> James, Andrew and we are waiting for your Acked-by: response.

In queue. FWIW, I'm about to post the current audit patchset to linux-audit,
push that crap to audit git and then I'm through with that turd. And
_finally_ can get to VFS queue sorting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at ttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at ttp://www.tux.org/lkml/

要するに「処理キューに入っていて意識しているから待て」ということのヨーダ

**login:Penguin** ◆XkB4aFXBWg · 2008/12/17(水) 13:55:02

追加のメッセージに、

That crap == audit patches for .29-rc1, that is.

とあるから、それに向けて一緒にいれてくれるつもりのヨーダ。
（本当は案外いいやつだったのかも）
理力を信じて待とう。

**login:Penguin** ◆XkB4aFXBWg · 2008/12/17(水) 14:07:06

>>626
>>>625
>返事来ましたな。
>queueがつまってないことを祈りましょうか。

劇即レスポンスに驚きますた。
Alには健康に留意して欲しいと思いまつ。

**login:Penguin** · 2008/12/17(水) 14:09:17

MortonやGH,Ingoらが超超人なだけじゃないか。
そんな人たちと一緒にするのが悪い。

**login:Penguin** ◆XkB4aFXBWg · 2008/12/17(水) 14:10:57

>>630
ごもっとも・・・（涙）

でも仕事をするならもっと普通の人とがいいな。

**デムパゆんゆん** · 2008/12/20(土) 21:55:20

ニイタカヤマノボレ奇襲シッパイセリ
kernel 2.6.27.10 patch rev 1989 tools 1980
此ヲ以て打電中止トス
しかし　kernel 2.6.27 2.6.28はちょっとのミスでカーネルパニックになる事が多い希ガス
神経質は体にｲｸﾅｲ

**デムパゆんゆん** · 2008/12/21(日) 06:20:13

kernel 2.6.27.10
知代パッチ当てずに素でビルドする
カ～ネルパニックだ　知代ちゃんは悪くない
今日の日記終わり

**login:Penguin** ◆XkB4aFXBWg · 2008/12/22(月) 18:12:20

信頼すべき筋の情報によるとKernel Watchの12月号にTOMOYOのことが
載っているらしい・・・。（早く見たいぞ）

ttp://www.atmarkit.co.jp/flinux/index/indexfiles/watchindex.html

また、F通の社内ではTOMOYOはあまり知られていないらしい・・・。
（ここに太鼓の達人で、叩き間違えたときにドン、カツがこぼすもじゃもじゃの画像を置きたい）

**デムパゆんゆん** · 2008/12/22(月) 22:39:20

不治痛は年中デスマで外界との接点がないのぢゃ
来年の元旦の朝　また寝袋から起きる事になりそうだ
と、マ板の叫びをコピペ

**名無しさん** · 2008/12/23(火) 23:10:14

kernel watchの中の人です。
熊猫さんに召還されましたー

誤解があるようなのですが、TOMOYOが知られていないのではなく、記事の論調が
「TOMOYOの事は ”と・う・ぜ・ん” 知ってるよな。この記事の読者層なら当たり前やんな」
という雰囲気だったので、たしなめられたのですよ。
突っ込んだ人はLinuxの外界はめちゃくちゃ詳しい人ですよ。

**デムパゆんゆん** · 2008/12/24(水) 01:21:53

革命の道は険しい　一歩進んで百歩下がる
全軍退却！

**デムパゆんゆん** · 2008/12/24(水) 01:37:19

＞突っ込んだ人はLinuxの外界はめちゃくちゃ詳しい人ですよ。
ぃぬっくすはド素人っつ～ことだな　了解

**login:Penguin** · 2008/12/24(水) 12:47:38

いやユーザランドのことだろ乗降

**login:Penguin** ◆XkB4aFXBWg · 2008/12/24(水) 21:14:21

TOMOYO Linuxのイベント情報を掲載するためのGoogle Calendarを作ってみますた。

ttp://www.google.com/calendar/embed?src=71t1cadacbb3ikis5h2mkfi0ao%40group.calendar.google.com&ctz=Asia/Tokyo

GmailなどGoogleのアカウントを持っていれば、自分のGoogle Calendarに
追加することができます。日本固有？のイベント情報は、件名を"JP - なんとか"
のようにしました。

HTMLでwebページに貼り付けることもできるので、はてなキーワードに
貼ってみました。Safari, Chrome, IE7で表示を確認しましたが何故か
FireFoxだと表示できません。

**login:Penguin** · 2008/12/27(土) 15:50:22

>>634
１月６日掲載予定だそうです。

**login:Penguin** ◆XkB4aFXBWg · 2008/12/27(土) 17:58:09

>>641
ご親切にありがとうございます。

**login:Penguin** · 2009/01/01(木) 05:17:21

ついにVFS拡張が取り込まれそうですねえ。

よかったよかった。

**login:Penguin** ◆XkB4aFXBWg · 2009/01/01(木) 08:17:58

>>643
Al Viroのgit-pull（取り込んでね、Linus）メッセージですね。
From: viro
Subject: [git pull] vfs patches, part 1
Date: December 31, 2008 4:43:56 PM JST
To: torvalds
Cc: linux-kernel@vger.kernel.org

>Kentaro Takeda (1):
> introduce new LSM hooks where vfsmount is available.

内容の検証はまだですが、Alはちゃんとキューを処理して
（約束を果たして）くれました。Alに感謝です。

みなさん、あけましておめでとうございます。

**login:Penguin** ◆XkB4aFXBWg · 2009/01/01(木) 08:26:41

LSMの修正が取り込まれたら、TOMOYOの本体を投稿する予定です。
今後もここで速報を流します。

**login:Penguin** ◆XkB4aFXBWg · 2009/01/01(木) 08:29:41

Al Viroの管理するvfsのgit treeの内容はwebでも見られます。
ttp://git.kernel.org/?p=linux/kernel/git/viro/vfs-2.6.git;a=log;h=vfs-

上記で[PATCH] introduce new LSM hooks where vfsmount is available.
が該当する部分です。

**login:Penguin** ◆XkB4aFXBWg · 2009/01/01(木) 08:54:25

参考情報を紹介しておきます。

gitについての情報源の情報
ttp://d.hatena.ne.jp/haradats/20081017

そもそもTOMOYOはなんで/いつからメインラインに挑戦してたんだっけ？
[Think IT] 第1回：熱い言葉に背中を押されて (1/3)
ttp://www.thinkit.co.jp/free/article/0709/8/1/

**login:Penguin** · 2009/01/01(木) 13:29:33

入りました。
ttp://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=be6d3e56a6b9b3a4ee44a0685e39e595073c6f0d

**login:Penguin** ◆XkB4aFXBWg · 2009/01/01(木) 16:16:46

>>648
了解

本体、本日14時過ぎに投稿済みです。

**login:Penguin** · 2009/01/02(金) 06:31:15

2.6.29-rc1が出てから、そいつ用のパッチにした方が
よかったんでないかと思ったり。

そうすれば-mm入りした時点でそのまま使えるし。

**login:Penguin** ◆XkB4aFXBWg · 2009/01/02(金) 14:12:59

>>650
>2.6.29-rc1が出てから、そいつ用のパッチにした方が
>よかったんでないかと思ったり。
TOMOYO本体は、対応するフックが取り込まれなければ投稿しても
仕方ありません。特に昨年末は、関係者助言に従い行儀よく、段階を
踏んで進めていましたから、「フックをAlに認めてもらってから
本体を承認してもらう」は重要でした。

ある意味ず～～～～～～～～っと投稿待ちの状態が続いていたわけで、
その間作者である先生はつらかったと思います（時々あばれていました）。

>そうすれば-mm入りした時点でそのまま使えるし。
当初は「まずは-mm、それから本家」と思っていたし、実際昔はそうだったと
思うのですが、Linusのtreeに入るとあまり途中のステップは本質的では
ないような気がしてきました。本体がLinusのgitに入ればその時点で
開発者はそのまま使えることになるわけで、むしろmmやnextのほうが
遅くなるのかも！？

**login:Penguin** · 2009/01/02(金) 15:41:46

本体がlinus-treeに入るためにはakpmセンセのレビューが必要なはずですが。

**login:Penguin** ◆XkB4aFXBWg · 2009/01/02(金) 15:53:07

>>652
言われてみればTOMOYO #14のパッチは、 mmotm 2008-12-30-16-05に
対するもので宛先はakpm先生でした・・・。

**login:Penguin** ◆XkB4aFXBWg · 2009/01/02(金) 16:32:26

Jonathan Corbetが書いたLinux Foundationのドキュメントを見てみました。
ttp://ldn.linuxfoundation.org/how-participate-linux-community

2.4: STAGING TREESのところにマージに至る段階について書かれていますが、
それを読むとやはり今も-mm treeがtesting and reviewingの場であることは
変わっておらず、典型的な開発サイクルでは約10%のパッチが-mm経由で
マージされると書いてありました（残り90%は？）。

**login:Penguin** ◆XkB4aFXBWg · 2009/01/02(金) 16:39:20

linux-nextについても言及されています。

The linux-next tree is, by design, a snapshot of what the mainline is expected
to look like after the next merge window closes（linux-nextは次のマージ
ウィンドウが閉じたときにどんな感じになるかのスナップショットを想定している）

とあり、次のマージウィンドウに向けた作業におけるfinding and fixing integration problem
有用性が実証されたと書いてあります。-mmとnextの関係は今後変わるでしょうけれども
今の段階ではやはり-mmが承認の場なのですね。

**login:Penguin** · 2009/01/03(土) 00:36:12

>>654
-mm経由しないのはlinusがメンテナ管理のリポジトリからpull

今回のVFSみたいに。

**login:Penguin** ◆XkB4aFXBWg · 2009/01/05(月) 22:03:08

1月1日にLKMLに投稿した#14のパッチについて、現在James Morrisが
レビューをしてくれているらしく、今日何件か質問がきています。

**login:Penguin** · 2009/01/05(月) 23:01:39

Kernel Watch 出ました。

**login:Penguin** · 2009/01/06(火) 00:43:25

12月版　カーネルゆく年くる年、2009年に来る機能はどれだ？（1/2）－＠IT
ttp://www.atmarkit.co.jp/flinux/rensai/watch2008/watch12a.html
マージに向けスパートを掛けるTOMOYO

**login:Penguin** ◆XkB4aFXBWg · 2009/01/06(火) 07:19:06

>>658
>>659
早速の連絡、ありがとうございました。
さすがkosakiさん、切れ味が良いですねぇ。

**login:Penguin** ◆XkB4aFXBWg · 2009/01/07(水) 07:52:11

Jamesが必要だというので、関係者に「どうよ？（いいでしょ？）」と
質問しています。Sergeが返答してくれましたが、期待していた答えとは
違っていて、議論再燃モードに突入が避けられないかもしれません（とほほ）。

ずっと姿を見なかったSergeとのやりとりに参入してきて、クールに
解説をしています。彼自身の意見（特にTOMOYOのマージに関する内容について）を
表明せず「解説」になっているのが、とてもStephenらしい。
Alにも質問をしていますがそちらはまだ・・・。

**login:Penguin** ◆XkB4aFXBWg · 2009/01/07(水) 07:54:33

>>661
入力が抜けてました。(_ _)

「参入してきた」のはStephenです。
「再燃」については、リストの扱いについて既に実質的に再燃しています。
Jamesに「最終的にはLinusの許可が」など恐ろしいことを言われています。

**login:Penguin** · 2009/01/07(水) 08:19:03

ありゃりゃ

Linuxの双方向リストでなく、単方向リストを使っている理由って何でしたっけ？
もし、その理由がメモリ消費量節約の程度、ここは妥協してもTOMOYOの本質には
あまり影響するような事ではないかと思います…。

**デムパゆんゆん** · 2009/01/07(水) 19:53:30

　　　　　　　　　　　　 -―￣￣｀ ―-- 　_
　　　　　　　　　　,　´ 　　　　　　　　,　　　~　￣､"ー､
　　　　　　　　_／　　　　　　　　　　/　,r　　 _　　　ヽノ
　　　　　　 , ´　　　　　　　　　　　/　/　　　 ● 　　i"
　　　　,／　　 ,|　　　　　　　　 /　/ ＿i⌒ ｌ|　i　　|
　　　と,-‐ ´￣　　　　　　　　 /　/ （⊂ ● j'__　　|
　　(´＿＿　　　､　　　　　　　/　/ 　￣!,__,u● 　　|　　　　あんなにたくさんのパッチ投稿したのに
　　　　　￣￣｀ヾ＿　　　　　し　　　　u　l|　i　／ヽ､　　　　叩かれるべきは、何かと糾弾してくるSELinux陣営なのに
　　　　　　　　 ,＿　＼　　　　　　　　　　　ﾉ(`'＿＿ノ　　　　　　わしがどれだけ、TOMOYOのことを考えていたと思うんじゃ？
　　　　　　　　(＿_ ￣~"　＿＿ , --‐一~⊂　　⊃＿　　　　　　　　　もうどうでもよくなった
　　　　　　　　　　￣￣￣　　　　　　⊂￣　　　　＿＿⊃　　　　　　　　　　温泉に行く
　　　　　　　　　　　　　　　　　　　⊂＿＿＿＿＿⊃

**login:Penguin** · 2009/01/07(水) 20:45:25

>>663
メモリ消費量節約だけが理由なら既存の双方向リストを使えばよいのですが、
（リストを walk している間に sleep する可能性がある処理を行えるように）
read lock free にしたいという理由から prev ポインタへのアクセスが
発生しないリスト（つまり単方向リスト）を使おうとしています。

**login:Penguin** · 2009/01/07(水) 20:59:51

ここで流れぶった切って、kernel時計の中の人が再登場。ずさっ

たとえば、memory cgroupなんか最初にmainline に入ったときは十分小さいコードを
実現するために、Xen等の仮想マシンを使った方が速いという頭おかしい実装だったけど、
マージ後にほぼすべてのコードが入れ替わるぐらいパッチを投げまくって、
まっとうな性能にしたりしてましたよ。

TOMOYOは性能だけじゃなく機能も豊富なのでいくつか落としてもいいんじゃない？
tomoyoディレクトリが一度出来てしまえば、それ以下のファイルはオレがメンテナだ
オレがackした、文句あっか。モードに出来るんだし。

**login:Penguin** · 2009/01/07(水) 21:29:58

未だにリストで揉めてるのか

**login:Penguin** · 2009/01/07(水) 21:56:27

LKML的には全然理由を説明してないに等しいからね

**デムパゆんゆん** · 2009/01/07(水) 22:06:02

>>668
　　　　　　　　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣＼
　　　　　　　　　　　　　　　／　　　　　　　　　　　　　　　　　　　　＼
　　　　　　　　　　　　　　／　　　　　　　　　　　　　　　　　　　　　　　＼
　　　　　　　　　　　　／　　　　　 ―――　　　　　　　　　　　　――― ＼
　　　　　　　　　　　／　　　　　　　　＿　　　　　　　　　　　　　　　＿　　＼
　　　　　　　　　／　　　　　 /´ ,..::::::::::.ヽヽ　　　　　　　/´ ,..:::::::::::.ヽヽ＼
　　　　　　　　／　　　　　　　　,'　 ,;::::::::::::::::::',　',　　　　　　　,'　 ,;:::::::::::::::::::',　',　＼
　　　　　　／　　　　　　　　　 {　 {:::::::::::::::::::::}　}　　　　　　 {　 {::::::::::::::::::::::}　｝　　＼　　　　>>665じゃLKML的には
　　　　　／　　　　　　　　　　　'、ヽ::::::::::::::／ /　　　　　　　 '、ヽ::::::::::::::／ /　　　＼　　　　ダメなの？
　　　　　|　　　　　　　　　　　　(;;;;;;;;;;）)￣　／　　　 |　　　　＼　￣　　　　　　　　　 |
　　　　　|　　　　　　　　　　／'　　　　 /　　　　 ∧　　　　　 ',　　　　　　　　　 |
　　　　　|　　　　　　　　　　｛{　　　　　｛　　　　 /　ヽ　　　　　｝　　　　　　　　 |
　　　　　|　　　　　　　　　　ヽ　　　　　　ヽ＿＿_／＿_ ＼＿＿_ﾉ　　　　　　　　　　｜ .　＿＿＿＿＿＿＿
　　　　　＼　　　　　　　　　　人　　　　　　　ヽ　　 ´　　｀　　'　　　　　　　　　　　　／　││
　　　　　　＼　　　　　（し.）　　　　　　　　　　　　　　　　　　　　　　　／　　　││
　　　　　　　　＼　　　　　　　｀¨　　　　　　　　　　　　　　　　　　　　　　　　　　　／　　　　..││
　　　　　　　　　/　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　＼　　　││
　　　　　　　／　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　＼　　││

**login:Penguin** ◆XkB4aFXBWg · 2009/01/08(木) 07:14:53

>>669
リストを含めて独自なものを持ち込もうとするのは、なかなか難しいものがあります。
「独自」にしたい理由があってそうしているわけで、そこには機能や効率、実装上の都合
などが含まれますが、それが自分（プロジェクト）の都合だけだと突破は非常に困難な気がします。
「早い段階（作り込む前）に提案しろ」という格言？は、そういうことです。

>ダメなの？
今は通してもらえるよう頑張ってみているところで、答えはこれから。

**login:Penguin** ◆XkB4aFXBWg · 2009/01/08(木) 08:34:28

今朝はSergeから2通メールがきています。in_execveとtomoyo独自のリスト、list1に
ついて各1通。いずれもtomoyo固有なので簡単ではありません。

list1については、
>The problem with list1 is that it *really* doesn't imply the
>characteristics you cite.
「list1についての問題は、（熊猫先生が）引用しているような（リストとしての
汎用的な）機能を本当に含んでいないことだよ」と書かれています。
in_execve（フラグ）については、credentialの対応で、Howellと調整して、
tomoyoにとって良い形で整理がついているのですが、Sergeはそこが気にいらないらしく、
対応が悩ましいところ。

**login:Penguin** ◆XkB4aFXBWg · 2009/01/08(木) 08:36:40

プロジェクトの外の人（できればカーネル開発有識者）から、肯定的な発言があると
ずいぶんと違うのですが、過去あまりそのようなことはありませんでした
（その反対はずいぶんたくさんあったのですが（笑））。
でふぁ

**login:Penguin** ◆XkB4aFXBWg · 2009/01/08(木) 12:06:11

>>671
中の人会議？の結果、alistについては、Sergeが言いたいのは名前が適切ではないという
意味で、in_execveについてはSergeの理解が不十分で事情をわかっていないのだろうと
整理されました（このあたりの事情について、David Howellが登場して説明してくれると
うれしいのですが、まだ現れていません）。James, Alへの質問は回答待ちです。

**デムパゆんゆん** · 2009/01/08(木) 12:44:49

>>670
　　　　　　　　　　　　 -―￣￣｀ ―-- 　_　　　
　　　　　　　　　　,　´ 　......... . .　　　,　　　~　￣"　ー _　　　　　ﾌﾞｯﾌﾞｰ　
　　　　　　　　_／...........::::::::::::::::: : : :/　,r:::::::::::.:::::::::.:: :::.........｀　、　　　　ﾌﾞｰﾝ
　　　　　　 , ´ : ::::::::::::::::::::::::::::::::::::/　/:::::::::::::: : ,ﾍ ::::::::::::::::::::::: : ヽ　　　　　　ｷｷｰ
　　　　,／:::;;;;;;;| : ::::::::::::::::::::::::::::::/　/::::::::::::::::::: ● ::::::::::::::::: : : :,／
　　　と,-‐ ´￣: ::::::::::::::::::::::::::::::/　/:::::::::::r(:::::::::`'::::::::::::::::::::::く
　　(´＿＿　 : : :;;:::::::::::::::::::::::::::/　/:::::::::::`(::::::::: ,ﾍ:::::::::::::::::::::: ヽ
　　　　　￣￣｀ヾ＿::::::::::::::::::::::し ::::::::::::::::::::::: :●::::::::::::::::::::::: : : :_>
　　　　　　　　 ,＿　＼:::::＿|￣￣ |＿::::::::::::::: `' _＿:::::::::-‐ ´
　　　　　　　　(＿_ ￣~"　|　　　　　　　| ))￣
　　　　　　　　　　　　　￣◎￣◎￣

**login:Penguin** · 2009/01/08(木) 22:10:06

いくつか。
１．今のlist1の実装はread lock free ではなく、TOMOYOの使い方が特殊なので
lockがいらないだけなので、名前に関してはSergeの意見のほうがまっとうな気がする
２．ただ、普通のlistを使うようにも書き直せる気がする。
他にもRCU使ってるけどlist使ってる奴いっぱいいるんだし。
ちゃんと検討してないからウソかもしれないが。
ただ、こういう直感的には、他に方法はあるんじゃね？と思わせるのは消極的反対を
有無ので、やっぱり追加説明は必要な気がする
３．in_execveについては、実は２案検討したんだけどもう１つの案は、
こんなにUglyなのでin_execveのほうが、はるかにマシなんだ。
とか言えるとよいと思う。
もちろん、きれいに出来るなら、それが一番良いんだけど、無理なら、これが一番マシ
ってのを説明する必要はあると思う
Serge案にしたがって、task->cred->security いじるようにしたら、ほら、こんなに
汚いパッチに。ってのは作れないの？

**login:Penguin** ◆XkB4aFXBWg · 2009/01/08(木) 22:52:53

>>675
気にかけていただいてありがたいです（涙）。

list1については、いろいろ（表に出しにくい）思惑などもあるようです。
（そのうち先生が降りてきて説明してくれるでしょう）
「名前に関してはSergeがまっとう」と「はるかにマシ」については、
それに近い形で午後3時頃先生から返信をしました。「はるかにマシ」というよりは、
「Sergeはできると思っているけれど、実はできないんだよ。だから
こうしているのさ」という感じですが。
（Sergeはすごく詳しいのですが、TOMOYOの実装については、Stephenほどには
理解していないようです）

**login:Penguin** ◆XkB4aFXBWg · 2009/01/08(木) 22:55:35

tomoyoとは関係ないのですが、LKMLに
PATCH [0/3]: Simplify the kernel build by removing perl.
という投稿をした人がいて、今日一日だけでごついレスがついています。
（「perlよりもbashのほうがたち悪いぜ」とか）

やはりこういう話題でもりあがる？のは世界共通のようです。

**login:Penguin** ◆XkB4aFXBWg · 2009/01/08(木) 22:58:12

>>677
すみません。よく見たら元メッセージの投稿は一週間前で、今日2通追加されただけでした。
（現在56レス）
Gmailは便利ですがスレッドが読みにくい・・・。（とGmailのせいにしちゃいけませんが）

**login:Penguin** ◆XkB4aFXBWg · 2009/01/08(木) 23:08:18

なかなか痛い攻撃を受けているJames Morris氏のブログに、「Kernel Securityの
Wikiを作ったから、書きたいやつは書けというエントリー」が追加されました。

ttp://james-morris.livejournal.com/37748.html

中を見たら、ちゃんと（一応？）TOMOYOのエントリーもあって一安心・・・。
SELinuxを含め、それぞれのプロジェクトでは情報があるのですが、
こうしてまとめたものは今まであまり見たことがありません。
活用されると良いと思います。

ttp://security.wiki.kernel.org/index.php/Projects

**login:Penguin** · 2009/01/09(金) 01:16:38

>>679
いやいやいや。控えめに見てもJamesは温情たっぷりのレビューしてると思いますよ。
自分的には「ちょっと、どうかな？」って時にもI hate とか oppose とか dislike とか言わずに、
ここの部分は自分以外に Ack もらってくれない？って言ってるだけなので。
なので、Linusじゃなくても別のだれかにAckをもらう作戦か、当該部分のパッチを捨てるか二択なんじゃないの。という気が。
捨てられる部分かどうか、知らないけど。（特にd_realpathとか）

**login:Penguin** ◆XkB4aFXBWg · 2009/01/09(金) 07:09:31

>>680
言われてみればそうかも・・・。
Jamesスマソ (T_T)

**login:Penguin** ◆XkB4aFXBWg · 2009/01/09(金) 07:26:21

少しですが、tomoyo-users-enに海外の方がくるようになりました。

ttp://lists.sourceforge.jp/mailman/archives/tomoyo-users-en/2009-January/thread.html

**login:Penguin** · 2009/01/09(金) 22:36:28

TOMOYOをレビューしてみた
LKMLに投稿してもあれるだけなので、先にこちらに書く

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

**login:Penguin** · 2009/01/09(金) 22:37:08

[2/10]
Singly Listも、ちょっと説得できてないようなので捨てる方向でつくり直した方がよい。というかこういう
コアピースは他のパッチのついでみたいな投稿のしかたじゃ入らないと思う。
Linusも以前、ダメだと言っていたよ。とか言われてるぐらいだし。

**login:Penguin** · 2009/01/09(金) 22:42:49

[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 に変換してるのも同じく筋悪

**login:Penguin** · 2009/01/09(金) 22:49:07

[4/10]
crazy なファイル名に対してエンコードを施さないとどうしてsafeでなくなるのか説明されていない。
カーネル内にパーサーを入れることはLinusがいやがっていることもあって、みんな気にするので
もっと詳しく説明した方がよい。

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

**login:Penguin** · 2009/01/09(金) 22:55:16

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

あと、

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

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

**login:Penguin** · 2009/01/09(金) 22:57:09

[6/10]
TOMOYOのファイルだけの変更だし、パーサーもないから、誰も文句を言わなさそう。
でもpatch descriptionが１行なのはちょっとひどい

**login:Penguin** · 2009/01/09(金) 22:59:52

[7/10]

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

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

**login:Penguin** · 2009/01/09(金) 23:07:02

[8/10]

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

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

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

って見えると思う

**login:Penguin** · 2009/01/09(金) 23:07:34

[9/10] [10/10] はNo problemと思いまする

**login:Penguin** ◆XkB4aFXBWg · 2009/01/09(金) 23:23:48

>>683
レビューありがとうございました。LKMLでは、投稿したとき通りかかった人が、
意見を述べる（そして立ち去る）という感じで、単独の方から全体を通してのコメントを
もらったのはこれが初めてです。（kosakiさんが書かれているように、全体を通してみるには
規模が大きくなってしまったということでもあります）

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

**login:Penguin** · 2009/01/09(金) 23:29:01

な、なんでオイラが kosaki って分かったのさ。
しょ、証拠はどこにあるんだ。うがががー

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

**login:Penguin** ◆XkB4aFXBWg · 2009/01/09(金) 23:32:52

やはり・・・。(=_=;

**login:Penguin** ◆XkB4aFXBWg · 2009/01/09(金) 23:39:42

コメントに対応するパッチのリンクを探しているのですが、lkml.orgに全部は
載っていないような気がします。見つけた分だけ貼っておきます。

0 ttp://lkml.org/lkml/2009/1/1/27
1 ttp://lkml.org/lkml/2009/1/1/30
2 ttp://lkml.org/lkml/2009/1/1/23
4 ttp://lkml.org/lkml/2009/1/1/28
5 ttp://lkml.org/lkml/2009/1/1/14
6 ttp://lkml.org/lkml/2009/1/1/18
8 ttp://lkml.org/lkml/2009/1/1/19
9 ttp://lkml.org/lkml/2009/1/1/29

**login:Penguin** ◆XkB4aFXBWg · 2009/01/09(金) 23:49:36

3 http://article.gmane.org/gmane.linux.kernel.lsm/7864/
7 ttp://article.gmane.org/gmane.linux.kernel.lsm/7869/
10 ttp://article.gmane.org/gmane.linux.kernel.lsm/7868/

**login:Penguin** ◆XkB4aFXBWg · 2009/01/10(土) 00:00:53

>>684
>Singly Listも、ちょっと説得できてないようなので捨てる方向でつくり直した方がよい。というかこういう
>コアピースは他のパッチのついでみたいな投稿のしかたじゃ入らないと思う。
>Linusも以前、ダメだと言っていたよ。とか言われてるぐらいだし。
ここで「コアピース」とは、汎用のという意味で書いていますか？

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

**login:Penguin** · 2009/01/10(土) 00:32:17

すごいな… おれもこんなレビューが書けるくらいになりたいもんだ…

**login:Penguin** · 2009/01/10(土) 04:04:54

>>697
パッチの最小化の観点からいうとver1はlock freeを捨てて、毎回mutexをとる作りにしてもええんちゃうの？＿
途中で寝たいから云々ってのはspin_lock を考えるから問題になるのですよね・・

**login:Penguin** · 2009/01/12(月) 16:34:37

>>676
熊猫は木曜の夜から風邪で、ほとんど布団の中です。

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

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

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

**login:Penguin** · 2009/01/12(月) 16:35:45

>>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 を探すのが精いっぱいでしょう。

**login:Penguin** · 2009/01/12(月) 16:36:55

>>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 としては
容認できません。

**login:Penguin** · 2009/01/12(月) 16:38:11

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

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

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

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

**login:Penguin** · 2009/01/12(月) 16:39:22

>>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 文が必要になります。

**login:Penguin** · 2009/01/12(月) 17:02:24

>>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攻略したほうがよくない？

**login:Penguin** · 2009/01/12(月) 17:11:01

>>701

＞過去の提案では security/tomoyo/ 以下だけの修正で済むようになっており、
＞TOMOYO を使わないカーネルのためにコードが大きくならないように配慮していました。
＞しかし、熊猫の記憶が正しければ、「このリストは共通部品として使えるから
＞security/tomoyo/ 以下に置くよりも include/linux/ 以下に置く方が良いのでは？」
＞「この処理は 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.

**login:Penguin** · 2009/01/12(月) 17:16:08

>>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の事なんか知らないから消極的反対から話がスタートしてしまうと思う。

**login:Penguin** · 2009/01/12(月) 17:24:23

>>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の価値観じゃなくて、コミュニティの価値観で議論・説得することだと思う。

**login:Penguin** · 2009/01/12(月) 17:24:44

>>702

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

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

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

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

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

**login:Penguin** · 2009/01/12(月) 17:33:49

>>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系くわしくないので、外しているかも）

**login:Penguin** · 2009/01/12(月) 17:37:18

>>702

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

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

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

**login:Penguin** · 2009/01/12(月) 17:41:04

>>703

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

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

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

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

－＞よし、Nack

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

**login:Penguin** · 2009/01/12(月) 17:45:52

>>703
>>704

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

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

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

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

**login:Penguin** ◆XkB4aFXBWg · 2009/01/12(月) 17:49:07

>>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)固有の名称に
するのが無難ですね。（今さらですが）

**login:Penguin** ◆XkB4aFXBWg · 2009/01/12(月) 17:57:44

>>701
やりとりを見ながら、色々今さら（あるいは今ごろ）モードに入っています。

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

**login:Penguin** ◆XkB4aFXBWg · 2009/01/12(月) 18:19:30

>>686
>僕の感想では、たんに、ログが見にくくなるだけだったら、こんな処理入れるな。というのが共通認識だと思う
>ログは人間がみるものなんだから、見る直前に加工すればいいじゃん。という疑問がわく。
>>703
に書かれているように「ログを見やすくするため」ではないというのがまずあります。
>crazy なファイル名に対してエンコードを施さないとどうしてsafeでなくなるのか説明されていない。
>カーネル内にパーサーを入れることはLinusがいやがっていることもあって、みんな気にするので
>もっと詳しく説明した方がよい。
descriptionで以下の内容を強調したほうが良いと思いました。
・tomoyoではポリシーの仕様として、0x20を含め全てのキャラクターを使えることを
　目指した（SELinuxではそうではありません）
・そのためにパス名の構成要素の正規化を行っている

**login:Penguin** ◆XkB4aFXBWg · 2009/01/12(月) 18:29:33

>>709
>上でも書いたけど、一番の問題は今のパッチディスクリプションに書いてある「TOMOYOはprevメンバは使わない」ってのは
>まったく理由になってないということ。
>他の何十のサブシステムがprev使ってないけど二十リストでやってる状況があるから。
>
>「メリットがなければコード追加しない」という価値観を前提に理論武装して説得するのがいいと思う。
同感です。

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

**login:Penguin** · 2009/01/12(月) 18:56:00

>>715

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

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

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

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

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

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