From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu May 1 16:16:08 2008 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Thu, 01 May 2008 16:16:08 +0900 Subject: [Tomoyo-dev 797] =?iso-2022-jp?b?GyRCJV0laiU3ITwkSyRoJGslYSViJWo7SE1RTkwkckApGyhC?= =?iso-2022-jp?b?GyRCOEIkOSRrNSFHPSRLJEQkJCRGGyhC?= Message-ID: <200805010716.m417G8Sg058224@www262.sakura.ne.jp> 　熊猫です。 　TOMOYO Linux では３種類のメモリ使用量を /proc/ccs/meminfo から取得できます。 # cat /proc/ccs/meminfo Shared: 65536 Private: 49152 Dynamic: 5106 Total: 119794 Shared: はパス名などの文字列を記憶しておくために永続的に使われている量、 Private: はアクセス許可などを記憶しておくために永続的に使われている量、 Dynamic: はアクセス許可のチェックや許可ログ／拒否ログを記憶しておくために 一時的に使われている量です。 Dynamic: に関してはプロファイルの MAX_GRANT_LOG および MAX_REJECT_LOG で 件数を指定することにより間接的に制限できますが、 Shared: と Private: に関しては 現状では上限を指定する方法がありません。そのため、理論上は、強制モードではない 状態でシステムを永遠に稼動させていると、カーネルが使える全てのメモリを 消費しつくしてしまう可能性があります。（現実にはその前に反応が遅くなって 使い物にならなくなります。） そこで、システム全体として、 Shared: と Private: （つまりポリシーを記憶 しておくために使われるメモリ量）の上限を指定できた方が便利かもと思い、 パッチを作成してみました。変更量としては＋１４行で実現できます。 http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/1.6.x/ccs-patch/memory-quota.diff?rev=1165&root=tomoyo&view=markup デフォルトで上限指定は無効です。 例えば上限として各１ＭＢに指定したい場合 echo Shared: 1048576 > /proc/ccs/meminfo echo Private: 1048576 > /proc/ccs/meminfo のように指定します。 既に 1.6.0 としてリリースしてしまった後ですが、 この機能を 1.6.x に取り込んだ方が良いでしょうか？ From takedakn ＠ nttdata.co.jp Thu May 1 19:23:19 2008 From: takedakn ＠ nttdata.co.jp (Kentaro Takeda) Date: Thu, 01 May 2008 19:23:19 +0900 Subject: [Tomoyo-dev 798] =?iso-2022-jp?b?TEtNTBskQiRYJE5CaBsoQjgbJEIyc0VqOUYkcjxCO1wbKEI=?= =?iso-2022-jp?b?GyRCJDckXiQ3JD8bKEI=?= Message-ID: <48199A17.5070301@nttdata.co.jp> 武田です。 先ほどLKMLに第8回投稿を実施しました。 http://lkml.org/lkml/2008/5/1/27 前回の議論を受けて、vfsヘルパ関数へvfsmountパラメータを渡すのではなく、 vfsmountに手が届くnamespaceの世界にLSMフックの追加する、 という方法を提案しています（1つ目のパッチ http://lkml.org/lkml/2008/5/1/28 ）。 既存のLSMモジュール（SELinux, Smack）のコードに影響を与えない というのがこの方法の最大のメリットです。 さらにコードをレビューしやすくするため、ファイルに対する アクセス制御機能のみに絞って投稿しています。 パッチファイルは7個、トータルで6000行ほどという素敵サイズです。 投降したパッチはSubversionにコミットしてあるので以下のURLで見られます。 http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/tags/lkml/8/patches/?root=tomoyo [tomoyo-dev 793] [tomoyo-users 432]の原田さんのメールにあるとおり、 これは自分たちだけで考えたことではなく、キーパーソンからの助言があり、 それを実現している、というのがこれまでの投稿との最大の違いです。 状況は現在進行形で動いています。 ぜひともご注目ください。 -- 武田健太郎 (Kentaro Takeda) takedakn ＠ nttdata.co.jp 株式会社NTTデータ 技術開発本部 SIアーキテクチャ開発センタ From yocto1 ＠ gmail.com Fri May 2 00:16:04 2008 From: yocto1 ＠ gmail.com (yocto) Date: Fri, 02 May 2008 00:16:04 +0900 Subject: [Tomoyo-dev 799] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwkSyRoJGslYSViJWo7SE1RTkwbKEI=?= =?iso-2022-jp?b?GyRCJHJAKThCJDkkazUhRz0kSyREJCQkRhsoQg==?= In-Reply-To: <200805010716.m417G8Sg058224@www262.sakura.ne.jp> References: <200805010716.m417G8Sg058224@www262.sakura.ne.jp> Message-ID: <4819deb5.28d7720a.7c9a.ffff8d67@mx.google.com> クスノです。 > Dynamic: に関してはプロファイルの MAX_GRANT_LOG および MAX_REJECT_LOG で > 件数を指定することにより間接的に制限できますが、 Shared: と Private: に関しては > 現状では上限を指定する方法がありません。そのため、理論上は、強制モードではない > 状態でシステムを永遠に稼動させていると、カーネルが使える全てのメモリを > 消費しつくしてしまう可能性があります。（現実にはその前に反応が遅くなって > 使い物にならなくなります。） 強制モードでは*ない*時ですよね、その状態で永遠に稼動させるというの はどうなんでしょ... 学習モードか確認モードで上限を指定したい時が想像できないのですが、 あるんでしょうか？ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Fri May 2 22:48:01 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Fri, 2 May 2008 22:48:01 +0900 Subject: [Tomoyo-dev 800] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwkSyRoJGslYSViJWo7SE1RTkwbKEI=?= =?iso-2022-jp?b?GyRCJHJAKThCJDkkazUhRz0kSyREJCQkRhsoQg==?= In-Reply-To: <4819deb5.28d7720a.7c9a.ffff8d67@mx.google.com> References: <200805010716.m417G8Sg058224@www262.sakura.ne.jp> <4819deb5.28d7720a.7c9a.ffff8d67@mx.google.com> Message-ID: <200805022248.IDH57836.PNPGStPEPWtNUFZ@I-love.SAKURA.ne.jp> 　熊猫です。 　Wiki 転載ありがとうございます。＞クスノさん 　今日、 1.5.4 と 1.6.1 のリリース決裁が完了したそうですので、近日中にリリースしたいと思います。 内心では今日が大安なので今日出したいですが、ＧＷ明け前に完了するとは想像していなかったので 全然準備をしていませんでした。 > 強制モードでは*ない*時ですよね、その状態で永遠に稼動させるというの > はどうなんでしょ... > > 学習モードか確認モードで上限を指定したい時が想像できないのですが、 > あるんでしょうか？ アクセス制御用途としてではなく、アクセス解析用途として使う場合には、 強制モードにしないままずっと使い続けるというケースがあると思います。 そんな時に、例えば６４ＭＢしかメモリを積んでいないマシンで ３２ＭＢもポリシーのために費やしてしまったとかいった事態を避けるのには有効です。 TOMOYO Linux はプログラムの実行時にデフォルトでドメイン遷移を行う（強制モードでなければ 自動的に新規作成して遷移する）ようになっていますが、プログラムの実行要求時にドメインの新規作成に 失敗した場合（即ち、ドメイン名が４０００文字以上となったか、あるいはメモリ不足によりドメイン名を 記憶しておくことができなかった場合）には（強制モードでなくても）プログラムの実行要求を拒否するという 仕様となっています。そのため、 Memory Quota 機能を搭載していない現状でも、 （強制モードではないのに）まだドメインの定義されていないプログラムを実行できなくなってしまう可能性 （つまり、一部のプログラムが実行されなかったことにより想定外の結果が生じる危険性）があるわけですが、 Memory Quota 機能を搭載した場合にはその可能性（危険性）が増加します。 実は、 1.6.0 では、（強制モードではない状態で）プログラムの実行要求時にドメインの新規作成に失敗した場合に、 -ENOMEM を返すべきところで 0 を返してしまっていたために、 「ドメイン遷移に失敗したためにプログラムの実行要求が拒否される」はずが 「ドメイン遷移を行わないままプログラムの実行要求が許可される」という想定外の動作をしていたことが判明しました。 つまり、前の段落で説明した仕様通りの動作をしていなかったのです。 1.5.x まではプログラムの実行要求を拒否していたので、（ subversion 上にある） 1.6.1-rc では 拒否するように修正しましたが、この「想定外の動作」を「新しい仕様」として定義してやると、 プログラムの実行要求時にドメインの新規作成に失敗した場合でも （強制モードでなければ）プログラムの実行要求が拒否されないようになるので、 前の段落で説明した可能性（危険性）を回避することができるようになります。 Memory Quota 機能を思い立って、むしろ 1.6.0 の振る舞いの方が望ましいのではないかと思うようになりました。 From yocto1 ＠ gmail.com Sat May 3 22:09:48 2008 From: yocto1 ＠ gmail.com (yocto) Date: Sat, 03 May 2008 22:09:48 +0900 Subject: [Tomoyo-dev 801] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwkSyRoJGslYSViJWo7SE1RTkwbKEI=?= =?iso-2022-jp?b?GyRCJHJAKThCJDkkazUhRz0kSyREJCQkRhsoQg==?= In-Reply-To: <200805022248.IDH57836.PNPGStPEPWtNUFZ@I-love.SAKURA.ne.jp> References: <200805010716.m417G8Sg058224@www262.sakura.ne.jp> <4819deb5.28d7720a.7c9a.ffff8d67@mx.google.com> <200805022248.IDH57836.PNPGStPEPWtNUFZ@I-love.SAKURA.ne.jp> Message-ID: <481c641d.18bb720a.08f6.39dc@mx.google.com> クスノです。 > 　熊猫です。 > > 　Wiki 転載ありがとうございます。＞クスノさん > > 　今日、 1.5.4 と 1.6.1 のリリース決裁が完了したそうですので、近日中にリリースしたいと思います。 > 内心では今日が大安なので今日出したいですが、ＧＷ明け前に完了するとは想像していなかったので > 全然準備をしていませんでした。 > > > 強制モードでは*ない*時ですよね、その状態で永遠に稼動させるというの > > はどうなんでしょ... > > > > 学習モードか確認モードで上限を指定したい時が想像できないのですが、 > > あるんでしょうか？ > > アクセス制御用途としてではなく、アクセス解析用途として使う場合には、 > 強制モードにしないままずっと使い続けるというケースがあると思います。 > そんな時に、例えば６４ＭＢしかメモリを積んでいないマシンで > ３２ＭＢもポリシーのために費やしてしまったとかいった事態を避けるのには有効です。 アクセス解析用途でも上限を超えると、アクセス解析出来ないということ ですよね。 TOMOYO Linuxがメモリを食いつぶすのを避けるというのはわかるのですが、 上限を指定して使うメリットが見えません。 > TOMOYO Linux はプログラムの実行時にデフォルトでドメイン遷移を行う（強制モードでなければ > 自動的に新規作成して遷移する）ようになっていますが、プログラムの実行要求時にドメインの新規作成に > 失敗した場合（即ち、ドメイン名が４０００文字以上となったか、あるいはメモリ不足によりドメイン名を > 記憶しておくことができなかった場合）には（強制モードでなくても）プログラムの実行要求を拒否するという > 仕様となっています。そのため、 Memory Quota 機能を搭載していない現状でも、 > （強制モードではないのに）まだドメインの定義されていないプログラムを実行できなくなってしまう可能性 > （つまり、一部のプログラムが実行されなかったことにより想定外の結果が生じる危険性）があるわけですが、 > Memory Quota 機能を搭載した場合にはその可能性（危険性）が増加します。 そうなんですね、知りませんでした。 > 実は、 1.6.0 では、（強制モードではない状態で）プログラムの実行要求時にドメインの新規作成に失敗した場合に、 > -ENOMEM を返すべきところで 0 を返してしまっていたために、 > 「ドメイン遷移に失敗したためにプログラムの実行要求が拒否される」はずが > 「ドメイン遷移を行わないままプログラムの実行要求が許可される」という想定外の動作をしていたことが判明しました。 > つまり、前の段落で説明した仕様通りの動作をしていなかったのです。 > 1.5.x まではプログラムの実行要求を拒否していたので、（ subversion 上にある） 1.6.1-rc では > 拒否するように修正しましたが、この「想定外の動作」を「新しい仕様」として定義してやると、 > プログラムの実行要求時にドメインの新規作成に失敗した場合でも > （強制モードでなければ）プログラムの実行要求が拒否されないようになるので、 > 前の段落で説明した可能性（危険性）を回避することができるようになります。 > Memory Quota 機能を思い立って、むしろ 1.6.0 の振る舞いの方が望ましいのではないかと思うようになりました。 私もそう思います。 強制モードでは無いのに拒否されるのは違うような気がします。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sun May 4 21:41:01 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 4 May 2008 21:41:01 +0900 Subject: [Tomoyo-dev 802] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwkSyRoJGslYSViJWo7SE1RTkwbKEI=?= =?iso-2022-jp?b?GyRCJHJAKThCJDkkazUhRz0kSyREJCQkRhsoQg==?= In-Reply-To: <481c641d.18bb720a.08f6.39dc@mx.google.com> References: <200805010716.m417G8Sg058224@www262.sakura.ne.jp> <4819deb5.28d7720a.7c9a.ffff8d67@mx.google.com> <200805022248.IDH57836.PNPGStPEPWtNUFZ@I-love.SAKURA.ne.jp> <481c641d.18bb720a.08f6.39dc@mx.google.com> Message-ID: <200805042141.HEI00532.EPtZGPNNWPUtFSP@I-love.SAKURA.ne.jp> 　熊猫です。 　ccs-patch-\*.diff を全て scripts/checkpatch.pl で通過できるようになりました。 include/linux/ fs/ と合わせて、コーディングスタイルの修正が全部完了しました。 （ただし、 include/linux/ fs/ はマルチバージョンに対応させているため、いくつか scripts/checkpatch.pl によるエラーや警告が出るのは避けられません。） > > > 強制モードでは*ない*時ですよね、その状態で永遠に稼動させるというの > > > はどうなんでしょ... > > > > > > 学習モードか確認モードで上限を指定したい時が想像できないのですが、 > > > あるんでしょうか？ > > > > アクセス制御用途としてではなく、アクセス解析用途として使う場合には、 > > 強制モードにしないままずっと使い続けるというケースがあると思います。 > > そんな時に、例えば６４ＭＢしかメモリを積んでいないマシンで > > ３２ＭＢもポリシーのために費やしてしまったとかいった事態を避けるのには有効です。 > > アクセス解析用途でも上限を超えると、アクセス解析出来ないということ > ですよね。 はい。ですが、６４ＭＢしかメモリを積んでいないマシンで６４ＭＢ全部をポリシーのために費やしてしまったために （主要なプロセスが OOM killer の手によって強制終了されてしまい）システムがハングアップしてしまうと 学習結果を取り出すことさえ不可能になってしまい、元も子もありません。 > > TOMOYO Linuxがメモリを食いつぶすのを避けるというのはわかるのですが、 > 上限を指定して使うメリットが見えません。 > だから、ハングアップを避けるために上限を指定できるようにしておくメリットはあると思います。 > > > TOMOYO Linux はプログラムの実行時にデフォルトでドメイン遷移を行う（強制モードでなければ > > 自動的に新規作成して遷移する）ようになっていますが、プログラムの実行要求時にドメインの新規作成に > > 失敗した場合（即ち、ドメイン名が４０００文字以上となったか、あるいはメモリ不足によりドメイン名を > > 記憶しておくことができなかった場合）には（強制モードでなくても）プログラムの実行要求を拒否するという > > 仕様となっています。そのため、 Memory Quota 機能を搭載していない現状でも、 > > （強制モードではないのに）まだドメインの定義されていないプログラムを実行できなくなってしまう可能性 > > （つまり、一部のプログラムが実行されなかったことにより想定外の結果が生じる危険性）があるわけですが、 > > Memory Quota 機能を搭載した場合にはその可能性（危険性）が増加します。 > > そうなんですね、知りませんでした。 > > > > 実は、 1.6.0 では、（強制モードではない状態で）プログラムの実行要求時にドメインの新規作成に失敗した場合に、 > > -ENOMEM を返すべきところで 0 を返してしまっていたために、 > > 「ドメイン遷移に失敗したためにプログラムの実行要求が拒否される」はずが > > 「ドメイン遷移を行わないままプログラムの実行要求が許可される」という想定外の動作をしていたことが判明しました。 > > つまり、前の段落で説明した仕様通りの動作をしていなかったのです。 > > 1.5.x まではプログラムの実行要求を拒否していたので、（ subversion 上にある） 1.6.1-rc では > > 拒否するように修正しましたが、この「想定外の動作」を「新しい仕様」として定義してやると、 > > プログラムの実行要求時にドメインの新規作成に失敗した場合でも > > （強制モードでなければ）プログラムの実行要求が拒否されないようになるので、 > > 前の段落で説明した可能性（危険性）を回避することができるようになります。 > > Memory Quota 機能を思い立って、むしろ 1.6.0 の振る舞いの方が望ましいのではないかと思うようになりました。 > > 私もそう思います。 > 強制モードでは無いのに拒否されるのは違うような気がします。 > 「無効モード」「学習モード」「確認モード」「強制モード」というのは、 「要求された処理」が「ポリシーに定義されている処理」と合致しなかった場合に どのような振る舞いをするかを指定するものです。つまり、「ポリシーとの比較後」の分岐なのです。 強制アクセス制御に限らず、動的にメモリを割り当てる全ての処理はメモリ不足で失敗する可能性があります。 例えば #! /bin/sh exec /tmp/makedomain.sh というプログラムを /tmp/makedomain.sh という名前で作成して /tmp/makedomain.sh を実行すると、 ドメイン名は無限に伸びていくわけですが、無限に長いドメイン名をサポートすることは不可能です。 ですから、 TOMOYO Linux で扱える文字列の長さは４０００文字までという制約を課しており、 それ以上の文字列を要求すると拒否されるようになっています。これは、「ポリシーとの比較前」の分岐なのです。 ですから、「強制モードでは無い」ことを理由に「要求された処理が拒否されることは絶対に許さない」と言われても どうしようもありません。 その上で、 1.6.0 では「ドメイン名が４０００文字に達した場合には、その時点のドメイン名を使って （つまりドメイン遷移を伴わないで）プログラムの実行を認める」という「 1.5.x までとは異なる動作」をしていました。 上記の /tmp/makedomain.sh を実行すると途中で拒否されることなく永遠に実行を継続できます。 Memory Quota 機能を導入した場合、 Quota に到達した時点でドメインが定義されていないプログラムを実行できなくなるため （シャットダウンスクリプトなどの）必要なプログラムを実行できなくなるというトラブルに遭遇する可能性が高くなるので、 「（強制モード以外では）ドメインを作成できなくてもプログラムの実行を認める」方が好都合なのではないかと考えています。 ドメイン遷移以外の処理（例えば ccs_check_open_permission()）に関しては、強制モードではない状態でメモリ不足になった場合は、 ”可能な限り”（ -ENOMEM ではなく 0 を返すことで）処理を継続できるようにする方向で実装していますので、 ドメイン遷移処理に関しても、強制モードではない状態では”可能な限り”処理を継続できる方が良いのかもしれません。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sun May 4 22:13:02 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 4 May 2008 22:13:02 +0900 Subject: [Tomoyo-dev 803] Re: Creating manager policy on 64bit system In-Reply-To: <878wyxq6zw.fsf@gmail.com> References: <87d4o9qvmu.fsf@gmail.com> <200804291113.IED05791.UWPEFPStZGPNNtP@I-love.SAKURA.ne.jp> <878wyxq6zw.fsf@gmail.com> Message-ID: <200805042213.ACB04120.GPPZtNSNPUPtEFW@I-love.SAKURA.ne.jp> 　熊猫です。 > 早速の対応ありがとうございます。書いてはいないだけで、もちろん > /usr/lib32 も存在していますよ。 ;) なるほど。 ところで、 Gentoo 向けの ccs-patch-\*.diff についてですが、 http://packages.gentoo.org/package/sys-kernel/gentoo-sources を見ると アーキテクチャ毎に stable/unstable がバラバラです。 tar ball に含めるリビジョンの基準として (1) 全てのアーキテクチャで stable なものを含める。（現時点では 2.6.24-r3 ） (2) x86 で stable なものを含める。（現時点では 2.6.24-r7 ） (3) stable でなくても最新のものを含める。（現時点では 2.6.25-r2 ） などが考えられますが、どのリビジョンを ccs-patch-1.6.1-\*.tar.gz に含めるべきでしょう？ subversion レポジトリ（リビジョン 1173 ）には 2.6.23-r9 用と 2.6.24-r4 用があります。 それから、 Gentoo では割とこまめにリビジョンが増えていくようですので、 ccs-patch-\*.diff から Makefile の EXTRAVERSION に -ccs を追加する部分を 予め削っておいた方が好都合でしょうか？ http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/1.6.x/ccs-patch/patches/ccs-patch-2.6.24-gentoo-r4.diff?root=tomoyo&view=markup From nao.aota ＠ gmail.com Mon May 5 08:47:15 2008 From: nao.aota ＠ gmail.com (Naohiro Aota) Date: Mon, 05 May 2008 08:47:15 +0900 Subject: [Tomoyo-dev 804] Re: Creating manager policy on 64bit system References: <87d4o9qvmu.fsf@gmail.com> <200804291113.IED05791.UWPEFPStZGPNNtP@I-love.SAKURA.ne.jp> <878wyxq6zw.fsf@gmail.com> <200805042213.ACB04120.GPPZtNSNPUPtEFW@I-love.SAKURA.ne.jp> Message-ID: <871w4h4oos.fsf@gmail.com> Tetsuo Handa writes: >> 早速の対応ありがとうございます。書いてはいないだけで、もちろん >> /usr/lib32 も存在していますよ。 ;) > > なるほど。 > > ところで、 Gentoo 向けの ccs-patch-\*.diff についてですが、 > http://packages.gentoo.org/package/sys-kernel/gentoo-sources を見ると > アーキテクチャ毎に stable/unstable がバラバラです。 > tar ball に含めるリビジョンの基準として > > (1) 全てのアーキテクチャで stable なものを含める。（現時点では 2.6.24-r3 ） > > (2) x86 で stable なものを含める。（現時点では 2.6.24-r7 ） > > (3) stable でなくても最新のものを含める。（現時点では 2.6.25-r2 ） > > などが考えられますが、どのリビジョンを ccs-patch-1.6.1-\*.tar.gz に含めるべきでしょう？ > subversion レポジトリ（リビジョン 1173 ）には 2.6.23-r9 用と 2.6.24-r4 用があります。 Gentoo のパッケージに深く関っているわけではないので、あくまでも個人的な意 見ですが、(1) と (2) との折衷案で、全てのアーキテクチャで stable なものと x86 で stable なものの両方を含めるのが一番いいのではないでしょうか。 ほと んどの人が x86 でしょうから大抵の人は stable の中で最新のものが使えますし、 そうでない人も stable なものを入手することができます。 > それから、 Gentoo では割とこまめにリビジョンが増えていくようですので、 > ccs-patch-\*.diff から Makefile の EXTRAVERSION に -ccs を追加する部分を > 予め削っておいた方が好都合でしょうか？ > http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/1.6.x/ccs-patch/patches/ccs-patch-2.6.24-gentoo-r4.diff?root=tomoyo&view=markup 実のところ ebuild ではその個所は削り取って patch をあてています。これは genpatch があてられる時にすでに EXTRAVERSION が書きかえられてしまうので、 patch で再度書き直す必要がないからです。 このように ebuild を使用してソースを取得するのには全く必要ない部分ではあ るのですが、gentoo-sources から ccs-sources を作る場合はカーネルの区別を するために必要な個所なので外さないほうがよいと思います。 ebuild の中で処 理するコストはほとんどないですし。 -- 青田 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Mon May 5 21:17:34 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 5 May 2008 21:17:34 +0900 Subject: [Tomoyo-dev 805] Re: =?iso-2022-jp?b?MS42LjAgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <200804012121.HHI23184.SNtFNtPPEPZWPGU@I-love.SAKURA.ne.jp> References: <200804012121.HHI23184.SNtFNtPPEPZWPGU@I-love.SAKURA.ne.jp> Message-ID: <200805052117.EFC43703.SEWNGPtFZNtPUPP@I-love.SAKURA.ne.jp> 　熊猫です。 > Debian Etch 以外はコピー＆ペーストで作成可能なシェルスクリプトにできましたが、 > Etch は Sarge と同じ手順ではうまくいきませんでした。 > Lenny ではどういう手順でコンパイルしているのでしょうか？＞やまねさん 　apt-get install linux-source-2.6.18 ではなく apt-get source linux-image-2.6.18-6-686 でインストールすると make-kpkg がオリジナルのバージョン番号（ 2.6.18.dfsg.1-18etch3 ）を 使ってパッケージを作成してくれるんですね。 ビルドスクリプトは以下のような感じになりそうです。 http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/1.6.x/ccs-patch/specs/build-debian_etch.sh?rev=1175&root=tomoyo&view=markup 　ただ、困ったことがあります。上記の手順で作成されるカーネルコンフィグには apt-get install linux-image-2.6.18-6-686 でインストールされる /boot/config-2.6.18-6-686 と 若干の差異があるようです。 tomoyo:/usr/src/linux-2.6-2.6.18.dfsg.1# diff /boot/config-2.6.18-6-686 .config 4c4 < # Thu Apr 24 07:52:13 2008 --- > # Mon May 5 19:20:21 2008 1127c1127 < CONFIG_BLK_DEV_IDEPNP=m --- > CONFIG_BLK_DEV_IDEPNP=y 1152d1151 < CONFIG_BLK_DEV_JMICRON=m 1234d1232 < CONFIG_SCSI_ARCMSR=m 2219d2216 < # CONFIG_I2C_ELEKTOR is not set 2310d2306 < # CONFIG_SENSORS_F75375S is not set 2338d2333 < CONFIG_SENSORS_W83793=m 3281d3275 < # CONFIG_ASFS_FS is not set 3462a3457 > CONFIG_SECURITY_SECLVL=y 3480c3475 < CONFIG_CRYPTO_SHA1=m --- > CONFIG_CRYPTO_SHA1=y 　バイナリでインストールしたカーネルに付属のコンフィグと、そのバイナリカーネルと 同じバージョンのソースから作られたコンフィグとが違うのは不思議ですね。 カーネルコンフィグが原因なのかどうか不明ですが、何かの原因で VMware Player で 起動できないという問題が発生しています。 具体的には、 initramfs.img に含まれている BusLogic.ko が自動的にロードされない ためＨＤＤを認識できず、そのため initramfs.img の中の scripts/local で Waiting for root file system... というメッセージが表示されます。 タイムアウト後にシェルが実行されたところで modprobe BusLogic と叩くと問題なく ロードされてＨＤＤが認識され、シェルを終了すると何事も無かったかのように initramfs.img の処理が再開され、正常に起動できます。 つまり、 BusLogic.ko と scsi_mod.ko と sd_mod.ko には問題点は無いのですが、 何故か自動的にはロードされません。 カーネルコンフィグのせいなのか udev 側の問題なのかは判りません。 いや、そもそも使っているソースコードが違っているのかも？ 　こちらの環境が壊れているのなら納得いきますが、 2.6.18-6-686 用の initramfs.img を作り直した場合には正常に動作しており、 2.6.18-6-686-ccs 用の initramfs.img だけで問題が起こります。 また、２つの initramfs.img を展開して比較しても、 lib/modules/2.6.18-6-686 と lib/modules/2.6.18-6-686-ccs 以外の 差異はありません。 　*.vmx ファイルに scsi0.virtualDev = "lsilogic" を追加してもらって BusLogic ではなく LSILogic にすると 2.6.18-6-686-ccs でも正常に起動できる ようですので、そうしてもらうしかないかなぁ？ From yocto1 ＠ gmail.com Wed May 7 00:04:12 2008 From: yocto1 ＠ gmail.com (yocto) Date: Wed, 07 May 2008 00:04:12 +0900 Subject: [Tomoyo-dev 806] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwkSyRoJGslYSViJWo7SE1RTkwbKEI=?= =?iso-2022-jp?b?GyRCJHJAKThCJDkkazUhRz0kSyREJCQkRhsoQg==?= In-Reply-To: <200805042141.HEI00532.EPtZGPNNWPUtFSP@I-love.SAKURA.ne.jp> References: <200805022248.IDH57836.PNPGStPEPWtNUFZ@I-love.SAKURA.ne.jp> <481c641d.18bb720a.08f6.39dc@mx.google.com> <200805042141.HEI00532.EPtZGPNNWPUtFSP@I-love.SAKURA.ne.jp> Message-ID: <48207371.1e018e0a.07c4.5ae7@mx.google.com> クスノです。 > 　熊猫です。 > > 　ccs-patch-\*.diff を全て scripts/checkpatch.pl で通過できるようになりました。 > include/linux/ fs/ と合わせて、コーディングスタイルの修正が全部完了しました。 > （ただし、 include/linux/ fs/ はマルチバージョンに対応させているため、いくつか > scripts/checkpatch.pl によるエラーや警告が出るのは避けられません。） > > > > > > > 強制モードでは*ない*時ですよね、その状態で永遠に稼動させるというの > > > > はどうなんでしょ... > > > > > > > > 学習モードか確認モードで上限を指定したい時が想像できないのですが、 > > > > あるんでしょうか？ > > > > > > アクセス制御用途としてではなく、アクセス解析用途として使う場合には、 > > > 強制モードにしないままずっと使い続けるというケースがあると思います。 > > > そんな時に、例えば６４ＭＢしかメモリを積んでいないマシンで > > > ３２ＭＢもポリシーのために費やしてしまったとかいった事態を避けるのには有効です。 > > > > アクセス解析用途でも上限を超えると、アクセス解析出来ないということ > > ですよね。 > > はい。ですが、６４ＭＢしかメモリを積んでいないマシンで６４ＭＢ全部をポリシーのために費やしてしまったために > （主要なプロセスが OOM killer の手によって強制終了されてしまい）システムがハングアップしてしまうと > 学習結果を取り出すことさえ不可能になってしまい、元も子もありません。 > > > > TOMOYO Linuxがメモリを食いつぶすのを避けるというのはわかるのですが、 > > 上限を指定して使うメリットが見えません。 > > > だから、ハングアップを避けるために上限を指定できるようにしておくメリットはあると思います。 上限を設定した場合に、利用者には上限を超えたことがどのようにしてわ かるのでしょうか。 > > > TOMOYO Linux はプログラムの実行時にデフォルトでドメイン遷移を行う（強制モードでなければ > > > 自動的に新規作成して遷移する）ようになっていますが、プログラムの実行要求時にドメインの新規作成に > > > 失敗した場合（即ち、ドメイン名が４０００文字以上となったか、あるいはメモリ不足によりドメイン名を > > > 記憶しておくことができなかった場合）には（強制モードでなくても）プログラムの実行要求を拒否するという > > > 仕様となっています。そのため、 Memory Quota 機能を搭載していない現状でも、 > > > （強制モードではないのに）まだドメインの定義されていないプログラムを実行できなくなってしまう可能性 > > > （つまり、一部のプログラムが実行されなかったことにより想定外の結果が生じる危険性）があるわけですが、 > > > Memory Quota 機能を搭載した場合にはその可能性（危険性）が増加します。 > > > > そうなんですね、知りませんでした。 > > > > > > > 実は、 1.6.0 では、（強制モードではない状態で）プログラムの実行要求時にドメインの新規作成に失敗した場合に、 > > > -ENOMEM を返すべきところで 0 を返してしまっていたために、 > > > 「ドメイン遷移に失敗したためにプログラムの実行要求が拒否される」はずが > > > 「ドメイン遷移を行わないままプログラムの実行要求が許可される」という想定外の動作をしていたことが判明しました。 > > > つまり、前の段落で説明した仕様通りの動作をしていなかったのです。 > > > 1.5.x まではプログラムの実行要求を拒否していたので、（ subversion 上にある） 1.6.1-rc では > > > 拒否するように修正しましたが、この「想定外の動作」を「新しい仕様」として定義してやると、 > > > プログラムの実行要求時にドメインの新規作成に失敗した場合でも > > > （強制モードでなければ）プログラムの実行要求が拒否されないようになるので、 > > > 前の段落で説明した可能性（危険性）を回避することができるようになります。 > > > Memory Quota 機能を思い立って、むしろ 1.6.0 の振る舞いの方が望ましいのではないかと思うようになりました。 > > > > 私もそう思います。 > > 強制モードでは無いのに拒否されるのは違うような気がします。 > > > 「無効モード」「学習モード」「確認モード」「強制モード」というのは、 > 「要求された処理」が「ポリシーに定義されている処理」と合致しなかった場合に > どのような振る舞いをするかを指定するものです。つまり、「ポリシーとの比較後」の分岐なのです。 すみません、ついていけてません...上記の分岐の話はドメイン遷移の時 だけですか？ 「無効モード」でもメモリは消費すると言うことですね。 > 強制アクセス制御に限らず、動的にメモリを割り当てる全ての処理はメモリ不足で失敗する可能性があります。 > 例えば > > #! /bin/sh > exec /tmp/makedomain.sh > > というプログラムを /tmp/makedomain.sh という名前で作成して /tmp/makedomain.sh を実行すると、 > ドメイン名は無限に伸びていくわけですが、無限に長いドメイン名をサポートすることは不可能です。 > ですから、 TOMOYO Linux で扱える文字列の長さは４０００文字までという制約を課しており、 > それ以上の文字列を要求すると拒否されるようになっています。これは、「ポリシーとの比較前」の分岐なのです。 > ですから、「強制モードでは無い」ことを理由に「要求された処理が拒否されることは絶対に許さない」と言われても > どうしようもありません。 > > その上で、 1.6.0 では「ドメイン名が４０００文字に達した場合には、その時点のドメイン名を使って > （つまりドメイン遷移を伴わないで）プログラムの実行を認める」という「 1.5.x までとは異なる動作」をしていました。 > 上記の /tmp/makedomain.sh を実行すると途中で拒否されることなく永遠に実行を継続できます。 > > Memory Quota 機能を導入した場合、 Quota に到達した時点でドメインが定義されていないプログラムを実行できなくなるため > （シャットダウンスクリプトなどの）必要なプログラムを実行できなくなるというトラブルに遭遇する可能性が高くなるので、 > 「（強制モード以外では）ドメインを作成できなくてもプログラムの実行を認める」方が好都合なのではないかと考えています。 > > ドメイン遷移以外の処理（例えば ccs_check_open_permission()）に関しては、強制モードではない状態でメモリ不足になった場合は、 > ”可能な限り”（ -ENOMEM ではなく 0 を返すことで）処理を継続できるようにする方向で実装していますので、 > ドメイン遷移処理に関しても、強制モードではない状態では”可能な限り”処理を継続できる方が良いのかもしれません。 ドメイン遷移以外はメモリ不足の時にモードの判断が出来る？ ドメイン遷移の時は現状では難しいと言うことでしょうか。 今更ながら勉強させてもらってますm(__)m From from-tomoyo-dev ＠ i-love.sakura.ne.jp Wed May 7 12:02:30 2008 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (Tetsuo Handa) Date: Wed, 07 May 2008 12:02:30 +0900 Subject: [Tomoyo-dev 807] Re: =?iso-2022-jp?b?GyRCJV0laiU3ITwkSyRoJGslYSViJWo7SE1RTkwbKEI=?= =?iso-2022-jp?b?GyRCJHJAKThCJDkkazUhRz0kSyREJCQkRhsoQg==?= In-Reply-To: <48207371.1e018e0a.07c4.5ae7@mx.google.com> References: <200805022248.IDH57836.PNPGStPEPWtNUFZ@I-love.SAKURA.ne.jp> <481c641d.18bb720a.08f6.39dc@mx.google.com> <200805042141.HEI00532.EPtZGPNNWPUtFSP@I-love.SAKURA.ne.jp> <48207371.1e018e0a.07c4.5ae7@mx.google.com> Message-ID: <200805070302.m4732UMv056568@www262.sakura.ne.jp> 　熊猫です。 > > > TOMOYO Linuxがメモリを食いつぶすのを避けるというのはわかるのですが、 > > > 上限を指定して使うメリットが見えません。 > > > > > だから、ハングアップを避けるために上限を指定できるようにしておくメリットはあると思います。 > > 上限を設定した場合に、利用者には上限を超えたことがどのようにしてわ > かるのでしょうか。 > printk() により ERROR: Out of memory for ccs_alloc_element(). または ERROR: Out of memory for ccs_save_name(). というメッセージが表示され、 続けて TOMOYO-ERROR: Domain 'ドメイン名' not defined. というメッセージが 表示されます。 これらのメッセージは syslog 経由で /var/log/messages にも保存されます。 さらに、 /proc/ccs/domain_policy を読み出したときに transition_failed という行を出力するようにしてみました。 これは、学習モードでアクセス許可の数が MAX_ACCEPT_ENTRY 個に到達したときに quota_exceeded という行を出力するのと同様の仕組みです。 http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/1.6.x/ccs-patch/fs/ccs_common.c?root=tomoyo&rev=1180&r1=1135&r2=1180 http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/1.6.x/ccs-patch/fs/tomoyo_domain.c?root=tomoyo&rev=1180&r1=1139&r2=1180 quota_exceeded とは、「学習中に MAX_ACCEPT_ENTRY 個に到達したために 自動的にアクセス許可を追加しなかったエントリがある」「そのため、 このまま強制モードに切り替えたら正常に動作しないだろう」ことを意味します。 transition_failed とは、「ドメインを新規作成しようとした時に、 Memory Quota に 達したか、あるいはドメイン名が４０００文字を超過してしまったために新規作成が できなかった」「そのため、あたかも keep_domain が指定されていたかのように 振舞った」「よって、このまま強制モードに切り替えたら正常に動作しないだろう」 ことを意味します。 どちらも、ポリシーのチューニングを促すことが目的のメッセージです。 > > 「無効モード」「学習モード」「確認モード」「強制モード」というのは、 > > 「要求された処理」が「ポリシーに定義されている処理」と合致しなかった場合に > > どのような振る舞いをするかを指定するものです。つまり、「ポリシーとの比較後」の分岐なのです。 > > すみません、ついていけてません...上記の分岐の話はドメイン遷移の時 > だけですか？ 上記の分岐の話はドメイン遷移以外の時です。 > 「無効モード」でもメモリは消費すると言うことですね。 はい。ドメイン遷移だけはモードに関係なく行われますので、 新しいドメインが作成されるたびにメモリを消費していきます。 > > ドメイン遷移以外の処理（例えば ccs_check_open_permission()）に関しては、強制モードではない状態でメモリ不足になった場合は、 > > ”可能な限り”（ -ENOMEM ではなく 0 を返すことで）処理を継続できるようにする方向で実装していますので、 > > ドメイン遷移処理に関しても、強制モードではない状態では”可能な限り”処理を継続できる方が良いのかもしれません。 > > ドメイン遷移以外はメモリ不足の時にモードの判断が出来る？ > ドメイン遷移の時は現状では難しいと言うことでしょうか。 現在のモードを取得する処理はメモリ割り当てを必要としないので 失敗することはありません。 それに対して、ドメインを遷移させる処理は メモリ割り当てを必要とするので失敗することがあります。 > 今更ながら勉強させてもらってますm(__)m 大歓迎です。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Thu May 8 01:05:08 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Thu, 8 May 2008 01:05:08 +0900 Subject: [Tomoyo-dev 808] Re: =?iso-2022-jp?b?MS42LjAgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <20080405122740.c2cc3760.henrich@debian.or.jp> References: <200804012121.HHI23184.SNtFNtPPEPZWPGU@I-love.SAKURA.ne.jp> <20080405122740.c2cc3760.henrich@debian.or.jp> Message-ID: <200805080105.JDF82818.tNPEPWPGUZSPNFt@I-love.SAKURA.ne.jp> 　熊猫です。 　ccs-patch-2.6.22-6.lenny1.diff をアップデートしようとして apt-get source linux-image-2.6.22-3-686 とやったのですが、 何故か linux-image-2.6.24-6 のソースがインストールされてしまいます。 もう、 lenny は 2.6.24 への移行を完了してしまって 2.6.22 には戻れない （ ccs-patch-2.6.22-6.lenny1.diff を tar ball に同梱しても使われない） ということなのでしょうか？ 一応、 apt-get install linux-source-2.6.22 とすると /usr/src/linux-source-2.6.22.tar.bz2 がインストールされるので ccs-patch-2.6.22-6.lenny1.diff を 同梱しておくほうが良いのかな？ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Fri May 9 23:59:27 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Fri, 9 May 2008 23:59:27 +0900 Subject: [Tomoyo-dev 809] Re: =?iso-2022-jp?b?MS42LjAgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <20080413192354.53f74f0c.henrich@debian.or.jp> References: <200804012121.HHI23184.SNtFNtPPEPZWPGU@I-love.SAKURA.ne.jp> <20080405122740.c2cc3760.henrich@debian.or.jp> <200804122331.BID78176.WtPPPUStNZGNEPF@I-love.SAKURA.ne.jp> <20080413192354.53f74f0c.henrich@debian.or.jp> Message-ID: <200805092359.JAJ30722.GPUWtNtPPPESZFN@I-love.SAKURA.ne.jp> 　熊猫＠1.5.4/1.6.1のリリース準備中です。 > > COPYING.ccs をコピーする必要が無いとしたら、 COPYING.ccs と README.ccs を > > 置くためだけに /usr/share/doc/tomoyo/ ディレクトリを作成するのは変な気がします。 > > 　Debian パッケージの changelog.Debian.gz と copyright ファイルが > 　置かれる必要があります。COPYING.ccs の内容は copyright ファイル > 　がカバーします。 なるほど。でも、 changelog.Debian.gz と copyright は Debian 固有のファイルですので ディストリビューション非依存のファイルである tar ball では現状維持とさせてください。 やまねさんの方で deb パッケージ化する際に /usr/share/doc/tomoyo/ を作成して changelog.Debian.gz と copyright が置かれるようにカスタマイズしていただいて構いません。 From henrich ＠ debian.or.jp Sat May 10 01:53:24 2008 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 10 May 2008 01:53:24 +0900 Subject: [Tomoyo-dev 810] Re: =?iso-2022-jp?b?MS42LjAgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <200805092359.JAJ30722.GPUWtNtPPPESZFN@I-love.SAKURA.ne.jp> References: <200804012121.HHI23184.SNtFNtPPEPZWPGU@I-love.SAKURA.ne.jp> <20080405122740.c2cc3760.henrich@debian.or.jp> <200804122331.BID78176.WtPPPUStNZGNEPF@I-love.SAKURA.ne.jp> <20080413192354.53f74f0c.henrich@debian.or.jp> <200805092359.JAJ30722.GPUWtNtPPPESZFN@I-love.SAKURA.ne.jp> Message-ID: <20080510015324.b8b23ba5.henrich@debian.or.jp> On Fri, 9 May 2008 23:59:27 +0900 Tetsuo Handa wrote: > なるほど。でも、 changelog.Debian.gz と copyright は Debian 固有のファイルですので > ディストリビューション非依存のファイルである tar ball では現状維持とさせてください。 　・配布物としては COPYING ファイルは必要 　　（なんで、わざわざ .ccs ってつけるんですか？違和感があります） 　・インストールするものとして（バイナリとして） COPYING ファイルは、必要ではない。 　・インストールするのであれば、ドキュメントをインストールする先としては 　　/usr/lib/ccs は不適当で、/usr/share/doc/tomoyo など /usr/share/ 以下が適当 　ということですが、理解に食い違いは無いですか？ >> オフライン向けドキュメントの内容が充実してから >> /usr/share/doc/tomoyo/ ディレクトリを作成すれば良いと思います。 　充実してようがいまいが、ディレクトリとして /usr/lib/ccs を利用するのが不適当 　である、もっと適当なディレクトリを利用すべきだ、という意見です。FHS 的には 　/lib と同様なディレクトリにドキュメントが置かれるのは異常です。 /usr/lib : Libraries for programming and packages Purpose /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. 　COPYING ファイルは architecture-dependent data ですか？ > やまねさんの方で deb パッケージ化する際に /usr/share/doc/tomoyo/ を作成して > changelog.Debian.gz と copyright が置かれるようにカスタマイズしていただいて構いません。 　それをしないと、Package Policy の重大な違反でアップロード出来ないので 　それは実施しています ;-) -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat May 10 02:31:34 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 10 May 2008 02:31:34 +0900 Subject: [Tomoyo-dev 811] Re: =?iso-2022-jp?b?MS42LjAgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <20080510015324.b8b23ba5.henrich@debian.or.jp> References: <20080405122740.c2cc3760.henrich@debian.or.jp> <200804122331.BID78176.WtPPPUStNZGNEPF@I-love.SAKURA.ne.jp> <20080413192354.53f74f0c.henrich@debian.or.jp> <200805092359.JAJ30722.GPUWtNtPPPESZFN@I-love.SAKURA.ne.jp> <20080510015324.b8b23ba5.henrich@debian.or.jp> Message-ID: <200805100231.EBH30259.EPPtNPtZUSPGWFN@I-love.SAKURA.ne.jp> 　熊猫です。 > > なるほど。でも、 changelog.Debian.gz と copyright は Debian 固有のファイルですので > > ディストリビューション非依存のファイルである tar ball では現状維持とさせてください。 > > 　・配布物としては COPYING ファイルは必要 同意します。 > 　　（なんで、わざわざ .ccs ってつけるんですか？違和感があります） 私が ccs を好きだからです。 それ以外には tar ball を展開するときに既に同名のファイルが存在する可能性があるからです。 実際、 ccs-patch-\*.tar.gz はカーネルソースディレクトリに展開するのでファイル名が衝突します。 > 　・インストールするものとして（バイナリとして） COPYING ファイルは、必要ではない。 ソースパッケージからであれバイナリパッケージからであれインストールする際に一緒にコピーされないと ユーザの目に留まらないと思うので、一緒にコピーされるようにしたいです。 > 　・インストールするのであれば、ドキュメントをインストールする先としては > 　　/usr/lib/ccs は不適当で、/usr/share/doc/tomoyo など /usr/share/ 以下が適当 私としては、ファイルが増えて階層化しないと不便になるまではディレクトリを作りたくないです。 man ページは /usr/share/man という既存のディレクトリがあるのでそこに置いていますが、 それ以外は README.ccs と COPYING.ccs 以外にドキュメントが存在しないので /usr/share/ 以下にディレクトリを作って移動させるのは現時点では行うつもりはありません。 > > 　ということですが、理解に食い違いは無いですか？ From henrich ＠ debian.or.jp Sat May 10 09:37:17 2008 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sat, 10 May 2008 09:37:17 +0900 Subject: [Tomoyo-dev 812] Re: =?iso-2022-jp?b?MS42LjAgGyRCJE4lMyVzJVElJCVrJHI7TyRhJF4bKEI=?= =?iso-2022-jp?b?GyRCJDkbKEI=?= In-Reply-To: <200805100231.EBH30259.EPPtNPtZUSPGWFN@I-love.SAKURA.ne.jp> References: <20080405122740.c2cc3760.henrich@debian.or.jp> <200804122331.BID78176.WtPPPUStNZGNEPF@I-love.SAKURA.ne.jp> <20080413192354.53f74f0c.henrich@debian.or.jp> <200805092359.JAJ30722.GPUWtNtPPPESZFN@I-love.SAKURA.ne.jp> <20080510015324.b8b23ba5.henrich@debian.or.jp> <200805100231.EBH30259.EPPtNPtZUSPGWFN@I-love.SAKURA.ne.jp> Message-ID: <20080510093717.51edf4bc.henrich@debian.or.jp> On Sat, 10 May 2008 02:31:34 +0900 Tetsuo Handa wrote: > > 　・インストールするものとして（バイナリとして） COPYING ファイルは、必要ではない。 > ソースパッケージからであれバイナリパッケージからであれインストールする際に一緒にコピーされないと > ユーザの目に留まらないと思うので、一緒にコピーされるようにしたいです。 　この点が理解できません。 　そのためにシステムとして不適当なことをやるのは構わない (FHS は無視)、 　ということですか？ 　 From yocto1 ＠ gmail.com Sun May 11 02:11:33 2008 From: yocto1 ＠ gmail.com (yocto) Date: Sun, 11 May 2008 02:11:33 +0900 Subject: [Tomoyo-dev 813] 1.6.1 Message-ID: <4825d748.26d7720a.2280.5592@mx.google.com> クスノです。 下記を置きました。 linux-image-2.6.18-18etch3-ccs-i586_1.6.1_i386.deb kernel-image-2.6.8-4-686-smp-ccs_2.6.8-17sarge1_i386.deb なぜかSargeの2.4がうまくいきません。 下記が2.4.27-10sarge7にならないので2.4.27-3-686-smp-ccsになってし まいます(-_-;) # apt-get source kernel-image-2.4.27-4-686-smp Reading Package Lists... Done Building Dependency Tree... Done Need to get 101kB of source archives. Get:1 http://www.ring.gr.jp sarge/main kernel-image-2.4.27-i386 2.4.27-10sarge5 (dsc) [1581B] Get:2 http://www.ring.gr.jp sarge/main kernel-image-2.4.27-i386 2.4.27-10sarge5 (tar) [99.8kB] Fetched 2B in 0s (19B/s) From henrich ＠ debian.or.jp Sun May 11 09:08:26 2008 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Sun, 11 May 2008 09:08:26 +0900 Subject: [Tomoyo-dev 814] Re: 1.6.1 In-Reply-To: <4825d748.26d7720a.2280.5592@mx.google.com> References: <4825d748.26d7720a.2280.5592@mx.google.com> Message-ID: <20080511090826.ffc58b32.henrich@debian.or.jp> 　やまねです。 　対応したパッケージのアップデートを行いました。何もなければ10日後には 　testing 入りです。 　http://packages.qa.debian.org/c/ccstools.html 　http://packages.qa.debian.org/c/ccspatch.html 　＃上記情報の更新はタイムラグがあります。 On Sun, 11 May 2008 02:11:33 +0900 yocto wrote: > なぜかSargeの2.4がうまくいきません。 　個人的には Sarge 、しかも 2.4 はもう対応外してもいいと思います。 　もうインストールメディアはアーカイブ行きですし… 　http://www.debian.or.jp/blog/debian31r8.html -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sun May 11 12:37:23 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 11 May 2008 12:37:23 +0900 Subject: [Tomoyo-dev 815] Re: 1.6.1 In-Reply-To: <4825d748.26d7720a.2280.5592@mx.google.com> References: <4825d748.26d7720a.2280.5592@mx.google.com> Message-ID: <200805111237.GHF90164.PPEPtNNUPZGtWFS@I-love.SAKURA.ne.jp> 　熊猫です。 > linux-image-2.6.18-18etch3-ccs-i586_1.6.1_i386.deb > kernel-image-2.6.8-4-686-smp-ccs_2.6.8-17sarge1_i386.deb 毎度ありがとうございます。 > なぜかSargeの2.4がうまくいきません。 > > 下記が2.4.27-10sarge7にならないので2.4.27-3-686-smp-ccsになってし > まいます(-_-;) > > # apt-get source kernel-image-2.4.27-4-686-smp > Reading Package Lists... Done > Building Dependency Tree... Done > Need to get 101kB of source archives. > Get:1 http://www.ring.gr.jp sarge/main kernel-image-2.4.27-i386 2.4.27-10sarge5 (dsc) [1581B] > Get:2 http://www.ring.gr.jp sarge/main kernel-image-2.4.27-i386 2.4.27-10sarge5 (tar) [99.8kB] > Fetched 2B in 0s (19B/s) 不思議ですね。こちらでは以下の設定で 2.4.27-10sarge7 のソースをインストールできました。 security.debian.org は含まれていますでしょうか？ tomoyo:~# cat /etc/apt/sources.list deb http://http.debian.or.jp/debian/ sarge main contrib non-free deb http://http.debian.or.jp/debian-non-US/ sarge/non-US main contrib non-free deb http://security.debian.org/ sarge/updates main contrib deb http://security.debian.org/ sarge/updates main contrib non-free deb-src http://http.debian.or.jp/debian/ sarge main contrib non-free deb-src http://http.debian.or.jp/debian-non-US/ sarge/non-US main contrib non-free deb-src http://security.debian.org/ sarge/updates main contrib deb-src http://security.debian.org/ sarge/updates main contrib non-free tomoyo:~# apt-get clean tomoyo:~# apt-get source kernel-image-2.4.27-4-686-smp Reading Package Lists... Done Building Dependency Tree... Done Need to get 103kB of source archives. Get:1 http://security.debian.org sarge/updates/main kernel-image-2.4.27-i386 2.4.27-10sarge7 (dsc) [1582B] Get:2 http://security.debian.org sarge/updates/main kernel-image-2.4.27-i386 2.4.27-10sarge7 (tar) [101kB] Fetched 103kB in 0s (106kB/s) dpkg-source: extracting kernel-image-2.4.27-i386 in kernel-image-2.4.27-i386-2.4.27 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sun May 11 13:04:10 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 11 May 2008 13:04:10 +0900 Subject: [Tomoyo-dev 816] Re: 1.6.1 In-Reply-To: <20080511090826.ffc58b32.henrich@debian.or.jp> References: <4825d748.26d7720a.2280.5592@mx.google.com> <20080511090826.ffc58b32.henrich@debian.or.jp> Message-ID: <200805111304.ECI43793.PPZSPWEttUNFGNP@I-love.SAKURA.ne.jp> 　熊猫です。 > 　やまねです。 > 　対応したパッケージのアップデートを行いました。何もなければ10日後には > 　testing 入りです。 > 　http://packages.qa.debian.org/c/ccstools.html > 　http://packages.qa.debian.org/c/ccspatch.html > > 　＃上記情報の更新はタイムラグがあります。 毎度ありがとうございます。 以下のような Problems が表示されているようですが、放置しておいても大丈夫でしょうか？ * There were override disparities found in suite unstable: o linux-patch-tomoyo: Override says devel - extra, .deb says admin - extra それから、バイナリパッケージ（カーネルおよびツール）についてはどうしましょうか？ www.mithril-linux.org または osdn.dl.sourceforge.jp からバイナリパッケージを ダウンロードできるようにしたいのですが、 http://www.mithril-linux.org/~henrich/debian/package/linux-image/ にある バイナリパッケージは 1.5.0 のままとなっています。 やまねさんにとってバイナリパッケージの作成作業が負担になるようでしたら こちらでバイナリパッケージを作って osdn.dl.sourceforge.jp にアップロードしますし、 負担にならないのであればやまねさんがバイナリパッケージを作って www.mithril-linux.org への アップロードおよび apt レポジトリのアップデートをしていただきたいと思っています。 よろしくお願いします。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sun May 11 15:03:33 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 11 May 2008 15:03:33 +0900 Subject: [Tomoyo-dev 817] Re: 1.6.1 In-Reply-To: <4825d748.26d7720a.2280.5592@mx.google.com> References: <4825d748.26d7720a.2280.5592@mx.google.com> Message-ID: <200805111503.IEE81767.UtPtPZWPNSPGNEF@I-love.SAKURA.ne.jp> 　熊猫です。 　Wiki をアップデートしました。 http://tomoyo.sourceforge.jp/wiki/?HowToMakeKernelPackage 　1.5.4 / 1.6.1 では、 rpm パッケージでインストールされるカーネルについては rpm パッケージを作成するための spec ファイルを同梱する代わりに spec ファイルを作成するためのスクリプトだけを同梱することで tar ball のサイズの減少を図っています。 http://sourceforge.jp/projects/tomoyo/files/?release_id=30297#30297 また、 deb パッケージでインストールされるカーネルについては deb パッケージを作成するためのスクリプト（ i686 用です）を同梱していますので、 スクリプトを実行するだけでダウンロードからコンパイルまで実行されるようになっています。 > linux-image-2.6.18-18etch3-ccs-i586_1.6.1_i386.deb 以前は make-kpkg の --revision オプションで TOMOYO Linux のバージョンを指定していましたが、 現在（ビルドスクリプト）では --revision オプションを指定するのではなく、 apt-get source で インストールされるソースコードで指定されているリビジョンをそのまま使うようになっています。 ビルドスクリプトを使うと linux-image-2.6.18-6-686-ccs-i686_2.6.18.dfsg.1-18etch3_i386.deb という名前で 作成されるはずです。（それを、 TOMOYO Linux のバージョンが判るようにするために linux-image-2.6.18-6-686-ccs1.6.1-i686_2.6.18.dfsg.1-18etch3_i386.deb のようにリネームして リリース物件に登録します。） 説明するのが遅くなってごめんなさい。今回はこのままで構いませんので、次回からはビルドスクリプトをご利用ください。 　よろしくお願いします。 From nao.aota ＠ gmail.com Sat May 17 19:22:27 2008 From: nao.aota ＠ gmail.com (Naohiro Aota) Date: Sat, 17 May 2008 19:22:27 +0900 Subject: [Tomoyo-dev 818] =?iso-2022-jp?b?Y2NzLXBhdGNoIDEuNi4xIBskQiROGyhCIDIuNi4yNSA=?= =?iso-2022-jp?b?GyRCTVElUSVDJUEbKEI=?= Message-ID: <87wslt2pss.fsf@yue.homenetwork> 青田です。 1.6.1 の ./patches/ccs-patch-2.6.25.diff ですが fs/compat.c に /***** TOMOYO Linux start. *****/ #include /***** TOMOYO Linux end. *****/ がぬけてませんか? gentoo-sources-2.6.25-r3 に このパッチをあてたものをコンパイルしようとし たのですが、 compat.c のコンパイルが search_binary_handler_with_transition() が定義されていないと出て失敗して しまいます。 -- 青田 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat May 17 19:31:18 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 17 May 2008 19:31:18 +0900 Subject: [Tomoyo-dev 819] Re: =?iso-2022-jp?b?Y2NzLXBhdGNoIDEuNi4xIBskQiROGyhCIDIuNi4yNSA=?= =?iso-2022-jp?b?GyRCTVElUSVDJUEbKEI=?= In-Reply-To: <87wslt2pss.fsf@yue.homenetwork> References: <87wslt2pss.fsf@yue.homenetwork> Message-ID: <200805171931.IHI70358.PEPtPUZGNtFNSPW@I-love.SAKURA.ne.jp> 　熊猫です。 > 1.6.1 の ./patches/ccs-patch-2.6.25.diff ですが fs/compat.c に > > /***** TOMOYO Linux start. *****/ > #include > /***** TOMOYO Linux end. *****/ > > がぬけてませんか? 　あ、確かに ccs-patch-2.6.25.diff と ccs-patch-2.6.25-14.fc9.diff から 抜けていますね。すぐに直します。 ccs-patch-2.6.11.diff: fs/compat.c | 11 +++ ccs-patch-2.6.12-2.3.legacy_FC3.diff: fs/compat.c | 11 +++ ccs-patch-2.6.12.3-a9-13.diff: fs/compat.c | 11 +++ ccs-patch-2.6.12.diff: fs/compat.c | 11 +++ ccs-patch-2.6.13.diff: fs/compat.c | 11 +++ ccs-patch-2.6.14.diff: fs/compat.c | 11 +++ ccs-patch-2.6.15.7-ubuntu1.diff: fs/compat.c | 11 +++ ccs-patch-2.6.15.diff: fs/compat.c | 11 +++ ccs-patch-2.6.16-0vl76.33.diff: fs/compat.c | 11 +++ ccs-patch-2.6.16.54-0.2.5_SUSE.diff: fs/compat.c | 11 +++ ccs-patch-2.6.16.diff: fs/compat.c | 11 +++ ccs-patch-2.6.17-1.2142_FC4.diff: fs/compat.c | 11 +++ ccs-patch-2.6.17.14-ubuntu1.diff: fs/compat.c | 11 +++ ccs-patch-2.6.17.diff: fs/compat.c | 11 +++ ccs-patch-2.6.18-18etch3.diff: fs/compat.c | 11 +++ ccs-patch-2.6.18-53.1.19.el5.diff: fs/compat.c | 11 +++ ccs-patch-2.6.18-8.16AX.diff: fs/compat.c | 11 +++ ccs-patch-2.6.18.8-0.9_SUSE.diff: fs/compat.c | 11 +++ ccs-patch-2.6.18.diff: fs/compat.c | 11 +++ ccs-patch-2.6.19.diff: fs/compat.c | 11 +++ ccs-patch-2.6.20-1.2320.fc5.diff: fs/compat.c | 11 +++ ccs-patch-2.6.20.3-ubuntu1.diff: fs/compat.c | 11 +++ ccs-patch-2.6.20.diff: fs/compat.c | 11 +++ ccs-patch-2.6.21.diff: fs/compat.c | 11 +++ ccs-patch-2.6.22-6.lenny1.diff: fs/compat.c | 5 + ccs-patch-2.6.22.14-72.fc6.diff: fs/compat.c | 5 + ccs-patch-2.6.22.17-0.1_SUSE.diff: fs/compat.c | 5 + ccs-patch-2.6.22.9-ubuntu1.diff: fs/compat.c | 5 + ccs-patch-2.6.22.diff: fs/compat.c | 5 + ccs-patch-2.6.23-5.diff: fs/compat.c | 5 + ccs-patch-2.6.23-gentoo-r9.diff: fs/compat.c | 5 + ccs-patch-2.6.23.15-80.fc7.diff: fs/compat.c | 5 + ccs-patch-2.6.23.diff: fs/compat.c | 5 + ccs-patch-2.6.24-4lenny.diff: fs/compat.c | 5 + ccs-patch-2.6.24-gentoo-r7.diff: fs/compat.c | 5 + ccs-patch-2.6.24.3-ubuntu1.diff: fs/compat.c | 5 + ccs-patch-2.6.24.7-92.fc8.diff: fs/compat.c | 5 + ccs-patch-2.6.24.diff: fs/compat.c | 5 + ccs-patch-2.6.25-14.fc9.diff: fs/compat.c | 2 ccs-patch-2.6.25.diff: fs/compat.c | 2 ccs-patch-2.6.8-14.diff: fs/compat.c | 11 +++ ccs-patch-2.6.8-17sarge1.diff: fs/compat.c | 11 +++ ccs-patch-2.6.9-42.21AX.diff: fs/compat.c | 16 ++++- ccs-patch-2.6.9-67.0.15.EL.diff: fs/compat.c | 16 ++++- From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat May 17 19:40:20 2008 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 17 May 2008 19:40:20 +0900 Subject: [Tomoyo-dev 820] Re: =?iso-2022-jp?b?Y2NzLXBhdGNoIDEuNi4xIBskQiROGyhCIDIuNi4yNSA=?= =?iso-2022-jp?b?GyRCTVElUSVDJUEbKEI=?= In-Reply-To: <200805171931.IHI70358.PEPtPUZGNtFNSPW@I-love.SAKURA.ne.jp> References: <87wslt2pss.fsf@yue.homenetwork> <200805171931.IHI70358.PEPtPUZGNtFNSPW@I-love.SAKURA.ne.jp> Message-ID: <200805171940.BFI18759.SENFGNPPUtPPZtW@I-love.SAKURA.ne.jp> 　熊猫です。 > 　あ、確かに ccs-patch-2.6.25.diff と ccs-patch-2.6.25-14.fc9.diff から > 抜けていますね。すぐに直します。 直しました。以下のアドレスから取得できます。 http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/trunk/1.6.x/ccs-patch/patches/ccs-patch-2.6.25.diff?rev=1226&root=tomoyo Fedora 9 の方はまだ環境を作っていないので来週直します。 ご指摘ありがとうございます。 From haradats ＠ nttdata.co.jp Wed May 21 11:39:32 2008 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Wed, 21 May 2008 11:39:32 +0900 Subject: [Tomoyo-dev 821] =?iso-2022-jp?b?U0QbJEJPIjpcIVYbKEJUT01PWU8gTGludXgbJEIkTkAkGyhC?= =?iso-2022-jp?b?GyRCMyYhVyROGyhCV2lraRskQjdHOlxIRyQsGyhCMS42LjE=?= =?iso-2022-jp?b?GyRCQlAxfiRLJEokaiReJDckPxsoQg==?= Message-ID: <48338B64.8010506@nttdata.co.jp> こんにちは。 サブジェクトが全てを語っていますが、一応説明しますと、 ・技術評論社さんのSoftware Design誌に2007年1月号から 　12月号まで、12回にわたり連載された「TOMOYO Linuxの世界」 　について、 ・技術評論社さんよりご承認いただき、Wikiへの転載を 　行っていましたが、 ・全ての記事のWikiへの転載が終了し、 ・使われていた画像の（現時点での最新バージョンである）1.6.1への 　対応が完了しました。 http://tomoyo.sourceforge.jp/wiki/?WorldOfTomoyoLinux 謝辞 記事のWiki化を快諾いただいた技術評論社さんに感謝します。 本文のWiki化については、tomoyo-devクスノ様の献身的な ご協力により実現しました。(T_T) 画像素材の1.6.1への対応に ついては、熊猫先生の自発的な努力により達成されました。(@_@; 二人の協力なくして、この壮大なプロジェクト（この作業が いかに大変かは実際にやってみないとわからないかもしれません） は達成されませんでした。ここに深く感謝します。(_ _; ご意見募集 はげまし、感謝、寄付、コメント、ご意見等ありましたら ご遠慮なくお送りください。 お願い 一度雑誌に書いた記事がこうして最新バージョンに対応して、 それを無料でWikiで読めるというのは、素晴らしいことだと 思います。是非是非多くの方々に活用いただきたいと 思います。 -- 原田季栄 (Toshiharu Harada) haradats ＠ nttdata.co.jp From haradats ＠ nttdata.co.jp Thu May 22 18:16:24 2008 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Thu, 22 May 2008 18:16:24 +0900 Subject: [Tomoyo-dev 822] Re: =?iso-2022-jp?b?W3RvbW95by11c2VycyA0MzNdIExLTUwbJEIkWCROGyhC?= =?iso-2022-jp?b?GyRCQmgbKEI4GyRCMnNFajlGJHI8QjtcJDckXiQ3JD8bKEI=?= In-Reply-To: <48199A17.5070301@nttdata.co.jp> References: <48199A17.5070301@nttdata.co.jp> Message-ID: <483539E8.9000808@nttdata.co.jp> 原田です。 TOMOYO Linuxメインライン化について、第8回投稿以降の状況に ついて報告します。実はいろいろありました。 On 5/1/2008 7:23 PM, Kentaro Takeda wrote: > 武田です。 > > 先ほどLKMLに第8回投稿を実施しました。 > http://lkml.org/lkml/2008/5/1/27 > > 前回の議論を受けて、vfsヘルパ関数へvfsmountパラメータを渡すのではなく、 > vfsmountに手が届くnamespaceの世界にLSMフックの追加する、 > という方法を提案しています（1つ目のパッチ http://lkml.org/lkml/2008/5/1/28 ）。 > 既存のLSMモジュール（SELinux, Smack）のコードに影響を与えない > というのがこの方法の最大のメリットです。 > > さらにコードをレビューしやすくするため、ファイルに対する > アクセス制御機能のみに絞って投稿しています。 > パッチファイルは7個、トータルで6000行ほどという素敵サイズです。 > > 投降したパッチはSubversionにコミットしてあるので以下のURLで見られます。 > http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/tags/lkml/8/patches/?root=tomoyo > > [tomoyo-dev 793] [tomoyo-users 432]の原田さんのメールにあるとおり、 > これは自分たちだけで考えたことではなく、キーパーソンからの助言があり、 > それを実現している、というのがこれまでの投稿との最大の違いです。 > > 状況は現在進行形で動いています。 > ぜひともご注目ください。 8番目の提案を投稿した直後、Stephenから下記のような（抜粋） メールをもらいました。 > This is NOT the approach we discussed. Instead of adding new hooks to > the callers where the vfsmount is reliably available, you are adding > hook calls at the same places as existing ones and passing nameidata > that may or may not have a vfsmount set. And you are still re-factoring > the core code into these pre_ functions, vs. just having your module > call permission() as needed to check DAC and if necessary duplicating > logic. Stephenの指示に従って作ったつもりのパッチが、実はそうでは なかったということです。また、「助言を受けても、それに従わないなら これ以上聞かないでくれ」とも言われました。 第8回の提案は、アプローチとしてはベストに近く、満を持しての 投稿をしたつもりだっただけに、またStephenの助言に従い 作業していたつもりだっただけに、このメッセージには 驚きましたし、激しく落ち込みました（数週間精神的なダメージを ひきずっていました）。「Stephenにアドバイスしてもらったオプションを 採用して・・・」と断りながら、彼が「これは違う」と驚く 内容のパッチを投稿してしまったことについて、Stephenに すまないと思いました。 その後、すれ違っている部分やTOMOYOに関する新しい情報などが 判明し、機能を限定すれば既存のLSMに無修正のモジュールを 作れることもわかったのですが、Stephenに相談したところ、 「それよりも今はMiklosが提案しているスレッドをウォッチしたほうが良い」 と言われ、投稿を見送っています。 http://lkml.org/lkml/2008/5/16/279 このMiklosの提案中のパッチは、もともとはr/o bind mount のための修正ですが、（たまたま）TOMOYOやAppArmorに とっても有用な修正になっています（ということは Miklosもそれを意識しているようです）。 このパッチがmergeされたら、それに対応した提案を 投稿します、というのが5月22日現在の状況です。 -- 原田季栄 (Toshiharu Harada) haradats ＠ nttdata.co.jp From takedakn ＠ nttdata.co.jp Thu May 22 20:37:36 2008 From: takedakn ＠ nttdata.co.jp (Kentaro Takeda) Date: Thu, 22 May 2008 20:37:36 +0900 Subject: [Tomoyo-dev 823] =?iso-2022-jp?b?TEtNTBskQiRKJEkkTiVhITwlaiVzJTAlaiU5JUgkchsoQmdt?= =?iso-2022-jp?b?YW5lGyRCJEclSyVlITwlOSUwJWshPCVXJEgkNyRGRkkkYBsoQg==?= Message-ID: <48355B00.5060001@nttdata.co.jp> 武田です。 TOMOYO Linuxそのものとは直接は関係ありませんが、 LKMLやLSM, fsdevelメーリングリストを過去ログも 含めてローカルから快適に読むためのTipsを紹介します。 LKML.orgやmarc.infoでは、Webブラウザ経由でメーリングリストを読むことができます。 しかし、柔軟な検索やスレッド表示の面から考えると、やはりローカルに落として読みたい！ とはいえ、普段使用する会社のアドレスで購読するのは すぐにメールボックスが溢れてしまうorz…のでしたくありません。 （Gmailはディスクに余裕はありますが、 　やはりWebブラウザ経由なので操作が限定されるのと、 　スレッド表示方法が独特なのが残念） そんな時に便利なのが、news.gmane.orgです。 ここでは各種メーリングリストがニュースグループの形式で提供されいます。 過去ログも含めニュースリーダで一括受信して読むことができるので、 普段から受信していなくても、必要な時に一気にローカルに落とすことができます。 もちろん落としてしまえばオフラインでも読めます。 感覚としてはメーリングリストの過去ログが詰まった公開POP/IMAPサーバでしょうか。 （ニュースグループはそういうもんですね。そもそも） ちなみに、Thunderbirdはニュースリーダとしても使えます。 「ファイル」→「新規作成」→「アカウント」→「ニュースグループアカウント」 で、ニュースサーバにnews.gmane.orgを指定してニュースグループアカウントを作ります。 できたアカウントを右クリックして、「購読」から必要なグループを選択してやればOKです。 TOMOYOに関係あるニュースグループ ・gmane.linux.kernel（LKML, カーネル全般） ・gmane.linux.kernel.lsm（LSM） ・gmane.linux.file-systems（ファイルシステム） 以上、ご参考まで。 -- 武田健太郎 From takedakn ＠ nttdata.co.jp Tue May 27 11:01:19 2008 From: takedakn ＠ nttdata.co.jp (Kentaro Takeda) Date: Tue, 27 May 2008 11:01:19 +0900 Subject: [Tomoyo-dev 824] =?iso-2022-jp?b?VWJ1bnR1IDguMDQgKyBUT01PWU8gMS42LjEgTGl2ZUNE?= =?iso-2022-jp?b?GyRCJHIlIiVDJVclRyE8JUgkNyReJDckPxsoQg==?= Message-ID: <483B6B6F.3070906@nttdata.co.jp> 武田です。 Ubuntu 8.04 + TOMOYO 1.6.1のLiveCDをアップデートしました。 本家ベース： http://tomoyo.sourceforge.jp/incoming/ubuntu-8.04-desktop-i386-tomoyo-1.6.1.iso 日本語ローカライズドベース： http://tomoyo.sourceforge.jp/incoming/ubuntu-ja-8.04-desktop-i386-tomoyo-1.6.1.iso MD5SUMは以下のものに変わりました。 cb9d270d07d05645536a7614cfeab521 ubuntu-8.04-desktop-i386-tomoyo-1.6.1.iso d668e29616fdf9d524ebd56d36297b3a ubuntu-ja-8.04-desktop-i386-tomoyo-1.6.1.iso 今回のアップデートでの変更点は以下のとおりです。 ・linux-restricted-moduleパッケージを導入しました。 　nvidia等のプロプライエタリなドライバが詰まったこのパッケージを、 　これまでのLiveCDではpurgeしてました。これにより 　nvidiaのボードで動作しない等の問題が解消されているはずです。 ・チュートリアルドキュメントを同梱しました。 ・5月26日夕方時点でのアップデートをかけました。 　Debianと派生ディストロに見つかったOpenSSH serverの問題 　（ http://www.jpcert.or.jp/at/2008/at080008.txt ）も解消済みです。 これまでのLiveCD（8.04+1.6.1）からハードディスクにインストールした環境をお持ちの方は、 linux-restricted-moduleが導入されていないと思います。 http://osdn.dl.sourceforge.jp/tomoyo/30299/linux-restricted-modules-2.6.24-16-ccs1.6.1_2.6.24.12-16.34_i386.deb をインストールすることで、各種プロプライエタリなハードウェアが正しく動作するようになるかもしれません。 某所でnvidiaのボードでTOMOYOが動作しないとの報告をいただき、 linux-restricted-moduleパッケージが不足していることに気づき 問題を解消できました。ご報告多謝です。m(_ _)m -- 武田健太郎 From takedakn ＠ nttdata.co.jp Tue May 27 21:23:14 2008 From: takedakn ＠ nttdata.co.jp (Kentaro Takeda) Date: Tue, 27 May 2008 21:23:14 +0900 Subject: [Tomoyo-dev 825] Re: =?iso-2022-jp?b?VWJ1bnR1IDguMDQgKyBUT01PWU8gMS42LjEgTGl2ZUNE?= =?iso-2022-jp?b?GyRCJHIlIiVDJVclRyE8JUgkNyReJDckPxsoQg==?= In-Reply-To: <483B6B6F.3070906@nttdata.co.jp> References: <483B6B6F.3070906@nttdata.co.jp> Message-ID: <483BFD32.1070608@nttdata.co.jp> 武田です。 LiveCDアップデートのアナウンス後すぐに、 Ubuntuのカーネルその他もろもろがアップデートされました orz カーネルは 2.6.24-16 から 2.6.24-17 になっています。 ということで、再度アップデートしたものをアップロードしました。あぁしんど。 本家ベース： http://tomoyo.sourceforge.jp/incoming/ubuntu-8.04-desktop-i386-tomoyo-1.6.1.iso 日本語ローカライズドベース： http://tomoyo.sourceforge.jp/incoming/ubuntu-ja-8.04-desktop-i386-tomoyo-1.6.1.iso MD5SUMは以下のものに変わりました。 f761e8d2c40de08599fc857e289a97b8 ubuntu-8.04-desktop-i386-tomoyo-1.6.1.iso 41391e3bdf0666d30f76f949f4a596a9 ubuntu-ja-8.04-desktop-i386-tomoyo-1.6.1.iso 今回のアップデートで、VMwareゲストOSとしてLinuxを使用しているときに 複数CPUを割り当てると固まることがある問題（ [tomoyo-users 436]で 熊猫先生が対処法を投げています ）が解消されているようです。 追伸。 明日から3日間、Linux World Expo＠東京ビッグサイトでTOMOYO Linuxを展示します。 西4ホール入ってすぐ左手に見える場所にブースを構えていますので、 機会があればぜひお越しください。 -- 武田健太郎 (Kentaro Takeda) takedakn ＠ nttdata.co.jp 株式会社NTTデータ 技術開発本部 SIアーキテクチャ開発センタ From matthew.szulik ＠ gmail.com Fri May 30 16:13:04 2008 From: matthew.szulik ＠ gmail.com (Matthew Szulik) Date: Fri, 30 May 2008 16:13:04 +0900 Subject: [Tomoyo-dev 826] =?iso-2022-jp?b?GyRCOjM6WSRKJDMkSCRHJDkkLBsoQg==?= Message-ID: <4d0fc8390805300013v78a0a54fj8244ba6378e748ce@mail.gmail.com> 秋元です。 http://tomoyo.sourceforge.jp/tomoyo-links.html 上記リンクの私のブログへのリンク表記が TOMOYO Linux @ Matthew'ss Blog となっていますが TOMOYO Linux @ Matthew's Blog に修正して頂けませんか。 From haradats ＠ gmail.com Fri May 30 16:29:28 2008 From: haradats ＠ gmail.com (Toshiharu Harada) Date: Fri, 30 May 2008 16:29:28 +0900 Subject: [Tomoyo-dev 827] Re: =?iso-2022-jp?b?GyRCOjM6WSRKJDMkSCRHJDkkLBsoQg==?= In-Reply-To: <4d0fc8390805300013v78a0a54fj8244ba6378e748ce@mail.gmail.com> References: <4d0fc8390805300013v78a0a54fj8244ba6378e748ce@mail.gmail.com> Message-ID: <9d732d950805300029s474b5d3xf528ced23544d35c@mail.gmail.com> 秋元様、 原田@Linux World Expoです。ご無沙汰しています。 2008/05/30 16:13 Matthew Szulik : > 秋元です。 > > http://tomoyo.sourceforge.jp/tomoyo-links.html > 上記リンクの私のブログへのリンク表記が > TOMOYO Linux @ Matthew'ss Blog > となっていますが > TOMOYO Linux @ Matthew's Blog > に修正して頂けませんか。 失礼いたしました。(_ _) 修正しましたのでご確認ください。 熊猫先生： ファイルを直に修正したので、あとでsvnのほうにも 登録をお願いします。 -- Toshiharu Harada haradats ＠ gmail.com