From from-tomoyo-users ＠ I-love.SAKURA.ne.jp Thu Sep 3 22:13:01 2009 From: from-tomoyo-users ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Thu, 3 Sep 2009 22:13:01 +0900 Subject: [Tomoyo-dev 1177] =?iso-2022-jp?b?VE9NT1lPIExpbnV4IDEuNy4wIBskQiRyJWolaiE8JTkbKEI=?= =?iso-2022-jp?b?GyRCJDckXiQ3JD8hIxsoQg==?= Message-ID: <200909032213.HBG97450.PtUSTZFSNTGPPVPtN@I-love.SAKURA.ne.jp> 熊猫です。 TOMOYO 1.7.0 では TOMOYO 2.2.0 から得られたフィードバックを元に仕様の見直しと 機能強化を行いました。構文の変化を伴うため TOMOYO 1.6.x との互換性はありません。 TOMOYO 1.6.x については、これ以降の機能追加は行いませんが、サポートは継続 されますので、 TOMOYO 1.6.x を利用中の方はバージョンアップする必要はありません。 変更点 （１）不要になったメモリを解放する仕組みの導入 従来はポリシーを記憶するために一度割り当てられたメモリは、ポリシーの削除後も 解放されませんでした。 TOMOYO 1.7.0 ではガベージコレクタ機能を搭載したことにより、ポリシーを削除 すると自動的にメモリが解放されるようになりました。 （２）長いパス名のサポート 従来は文字列の最大長が４０００バイト、１行の最大長が８１９２バイトという 制約がありました。そのため、４０００バイトを超えるような長いパス名が要求された 場合、アクセスが拒否されるケースがありました。 TOMOYO 1.7.0 では、ドメイン名と argv[] と envp[] 以外は（ kmalloc() で 割り当て可能な上限である）１２８キロバイトまでの文字列を扱えるようになりました。 （３）より詳細なプロファイル設定のサポート 従来はアクセス制御モードの指定は、カテゴリ（ファイル／ネットワークなど）単位 でしか行えませんでした。 TOMOYO 1.7.0 では、プロファイルの指定を細分化し、アクセス制御モード／アクセス ログの要・不要／ポリシー違反時にエラーメッセージを表示するかどうか／学習モードで if 節の学習をするかどうかの指定を項目単位で行えるようになりました。このメールの 末尾にプロファイルの設定例を示します。 （４）ファイルの属性値のチェックを強化 ファイルやディレクトリなどを作成する際に、指定可能なモードを制限できるように なりました。デバイスファイルを作成する際には、メジャー番号／マイナー番号も制限 できるようになりました。 allow_create file_to_be_created create_mode allow_mkdir directory_to_be_created create_mode allow_mkfifo fifo_to_be_created create_mode allow_mksock unix_domain_socket_to_be_created create_mode allow_mkblock block_device_to_be_created create_mode major_number minor_number allow_mkchar block_device_to_be_created create_mode major_number minor_number ファイルやディレクトリなどのモードを変更したり、所有者やグループを変更したり する際に指定可能な値を制限できるようになりました。 allow_chmod path_to_be_mode_changed chmod_mode allow_chown path_to_be_owner_changed user_id allow_chgrp path_to_be_group_changed group_id これらの機能強化により、想定外の属性を持ったデバイスファイルの作成 （例： char-1-5 という属性を持った /dev/null というファイル）を禁止したり、 /bin/sh などのプログラムに setuid/setgid ビットを付与するのを禁止したり、 ユーザのホームディレクトリ内のファイルに execute ビットを付与するのを禁止したり することができるようになります。 名前空間の操作に関する制限はドメイン単位で行えるようになりました。 allow_mount path_to_device path_to_mountpoint filesystem_type flags allow_unmount path_to_unmount allow_chroot new_root_directory allow_pivot_root new_root old_root 以下に示すその他の構文は従来と同じです。 allow_symlink symlink_to_be_created allow_link old_path new_path allow_rename old_path new_path allow_ioctl path_to_be_io_controlled cmd_number allow_read/write path_to_be_opened_for_reading_and_writing allow_execute program_to_be_executed allow_read path_to_be_opened_for_reading allow_write path_to_be_opened_for_writing allow_unlink path_to_be_deleted allow_rmdir directory_to_be_deleted allow_truncate file_to_be_truncated allow_rewrite file_to_be_rewritten （５）数値をグループ化する number_group 構文を追加 パス名をグループ化する path_group 構文、ＩＰアドレスをグループ化する address_group 構文に加えて、数値をグループ化する number_group 構文が追加 されました。ＤＡＣのモードや所有者ＩＤなども制限できるようになったわけですが、 単純な範囲指定だけでは記述しきれない場合があります。例えば 0640 0660 の両方を 指定したい場合、 allow_create /tmp/file 0640 allow_create /tmp/file 0660 のように繰り返しが必要になります。しかし、 number_group TMP_FILE_CREATE_MODES 0640 number_group TMP_FILE_CREATE_MODES 0660 のようにグループを定義してやることで、 allow_create /tmp/file @TMP_FILE_CREATE_MODES のように繰り返しを回避できます。 number_group 構文は、 TOMOYO を Android 上で動かす場合にも便利です。 （ http://sourceforge.jp/projects/tomoyo/docs/Part2_CELF_Android.pdf ） TOMOYO はＵＩＤに基づくアクセス制限もサポートしているので、 allow_execute /bin/sh if task.uid!=0 のような制限が可能です。 Android ではアプリケーション毎に異なるＵＩＤが 割り当てられますが、そのＵＩＤはインストール時まで不明です。そのため、 アプリケーションとそのアプリケーション用のポリシーとを一緒に配布したくても、 allow_read /data/data/package1/\* if task.uid=????? のように、 ????? の部分を確定できません。しかし、 allow_read /data/data/package1/\* if task.uid=@PACKAGE1_DATA_READERS のようにＵＩＤの部分を未定義のまま domain_policy.conf を作成し、 インストール時に判明したＵＩＤを number_group PACKAGE1_DATA_READERS 10000 のように exception_policy.conf に追加することで対処できるようになるため、 アプリケーションとそのアプリケーション用のポリシーとを一緒に配布することが 容易になります。 （６） alias 構文および allow_argv0 構文を廃止 従来はシンボリックリンクの実行は alias 構文で明示されない限りシンボリック リンクを解決したパス名の実行許可をチェックしていました。 TOMOYO 1.7.0 では シンボリックリンクを解決する前のパス名の実行許可をチェックするようにし、 シンボリックリンクを解決した後のパス名は allow_execute 構文の if 節の exec.realpath 部分でチェックするようになりました。同様に、最初の引数（ argv[0] ）は allow_execute 構文の if 節の exec.argv[0] 部分でチェックするように なりました。 /sbin/pidof が /sbin/killall5 へのシンボリックリンクとして提供されている環境で /sbin/pidof を実行するためのアクセス許可は以下のようになります。 allow_execute /sbin/pidof if exec.realpath="/sbin/killall5" exec.argv[0]="/sbin/pidof" （７）インストール時間の短縮 従来は初期状態のポリシーを生成する際、 alias 構文を生成するためにディスク 全体からシンボリックリンクを検索する処理を行う必要があったので、完了まで数分を 要していました。 TOMOYO 1.7.0 ではその必要が無くなったため数秒で完了するようになりました。 （８） system_policy.conf を廃止 system_policy.conf で使われていた構文の内、特定のローカルポート番号が ポート番号に 0 を指定した bind() によって使われてしまうのを防ぐ deny_autobind 構文は exception_policy.conf へ移動、それ以外の構文は domain_policy.conf へ 移動しました。 （９） syaoran ファイルシステムを廃止 allow_mkblock および allow_mkchar でデバイス番号も制限できるようになり、 allow_chmod と allow_chown と allow_chgrp でモードや所有者ＩＤ・グループＩＤの 変更も制限できるようになったため、ファイルシステム自身で制限する必要性は 無くなりました。そのため、 syaoran ファイルシステムは廃止されました。 （１０）排他制御の利用頻度を減らしたことによるボトルネックの解消 従来はメモリリークを検出するために TOMOYO 独自でメモリ使用量をカウントして いました。メモリリーク検出機能（ CONFIG_DEBUG_KMEMLEAK ）がカーネル 2.6.31 に マージされたことでもはや TOMOYO 独自でメモリリークを検出する必要性は無くなったと 判断し、メモリリークを検出するための排他制御が廃止されました。 （１１）フックの修正 TOMOYO の機能を呼び出すためのフックである ccs-patch-2.\*.diff を LSM 風の フックとして書き直しました。幾つかのフックは LSM のフックのすぐ隣にあります。 kill tkill および tgkill に対してはフックが掛けられていましたが、 sigqueue および tgsigqueue に対するフックが抜けていたので追加されました。 open(pathname, O_RDONLY) はファイルを読み込みのためにオープン、 open(pathname, O_WRONLY) はファイルを書き込みのためにオープン、 open(pathname, O_RDWR) はファイルを読み書きのためにオープンする方法ですが、 その他に open(pathname, 3) という、 ioctl のためだけにオープンする方法が あることが判明しました。 TOMOYO ではファイルの open() 時にパーミッションをチェックしますが、 ファイルの read()/write() 時にはパーミッションをチェックしません。 従来は、 open(pathname, 3) が要求された場合に allow_read/write をチェックして いましたが、 read() や write() を行わないのに allow_read/write をチェックする のは構文の意図に反しています。 ioctl() については allow_ioctl でチェックして いるので、 open(pathname, 3) の場合には allow_read/write をチェックしない ように改めました。 （１２）TOMOYO 本体の所在を security ディレクトリ以下に移動 fs/ ディレクトリから security/ccsecurity/ ディレクトリに移動し、カーネル コンフィグも File systems セクションから Security options セクションに 移動しました。名前も CONFIG_SAKURA CONFIG_TOMOYO CONFIG_SYAORAN から CONFIG_CCSECURITY に変更されました。 サポートしているカーネルバージョンは TOMOYO 1.6.8 と同じです。 バニラカーネル * 2.4.30 〜 2.4.37.5 * 2.6.11.12 〜 2.6.31-rc8 以下のディストリビューション * Fedora 9 (2.6.27.25-78.2.56.fc9) * Fedora 10 (2.6.27.30-170.2.82.fc10) * Fedora 11 (2.6.29.6-217.2.16.fc11) * CentOS 3.9 (2.4.21-60.EL) * CentOS 4.8 (2.6.9-89.0.9.EL) * CentOS 5.3 (2.6.18-128.7.1.el5) * Debian Etch (2.6.18-24etch4) * Debian Lenny (2.6.26-17lenny2) * Ubuntu 6.06 (2.6.15-54.79) * Ubuntu 8.04 (2.6.24-24.59) * Ubuntu 8.10 (2.6.27-14.39) * Ubuntu 9.04 (2.6.28-15.49) * Ubuntu 9.10 (2.6.31-9.29) * OpenSUSE 10.3 (2.6.22.19-0.4) * OpenSUSE 11.0 (2.6.25.20-0.5) * OpenSUSE 11.1 (2.6.27.29-0.1.1) * Vine Linux 4.2 (2.6.16-76.51vl4) * Asianux 2.0 (2.6.9-78.14AXS2) * Asianux 3.0 (2.6.18-53.25AXS3) * Gentoo * Hardened Gentoo * その他（リクエストをいただければ作成します。） コードサイズは合計 17020 行、TOMOYO 1.6.8 と比べて追加が 9812 行、 削除が 11344 行です。この統計を見ての通り、大幅な変更が行われたため、 まだいくつか不具合が残っているかもしれません。ユーザランドツールの調整や ドキュメント（ http://tomoyo.sourceforge.jp/1.7/ ）の更新も必要ですので、 しばらくはレポジトリを用いたバイナリパッケージのインストールは提供しません。 TOMOYO Linux では、 SELinux や Smack などと共存できることを目指しています。 LSM を用いたセキュリティモジュールのために様々なオブジェクトに対して security フィールドが提供されていますが、 TOMOYO ではほとんど活用していません。 もし、以下のように @@ -1480,6 +1482,10 @@ struct task_struct { /* bitmask of trace recursion */ unsigned long trace_recursion; #endif /* CONFIG_TRACING */ +#ifdef CONFIG_CCSECURITY + struct ccs_domain_info *ccs_domain_info; + u32 ccs_flags; +#endif }; /* Future-safe accessor for struct task_struct's cpus_allowed. */ タスク構造体に２つのメンバーを追加することが許されるのであれば、 TOMOYO は これらの security フィールドをより有効に活用できるモジュール（ SELinux や Smack など）に譲ることができます。 TOMOYO 1.x は LSM を使っていないので、 SELinux や Smack や AppArmor などと同時に利用することが可能です。 どうぞご活用ください。 最後に、プロファイルの設定例について示します。 PROFILE_VERSION=20090903 PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes symlink.target=yes } PREFERENCE::permissive={ verbose=yes } PREFERENCE::enforcing={ verbose=yes penalty=0 } 0-COMMENT=-----Disabled Mode----- 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } 1-COMMENT=-----Learning Mode----- 1-CONFIG={ mode=learning grant_log=yes reject_log=yes } 2-COMMENT=-----Permissive Mode----- 2-CONFIG={ mode=permissive grant_log=yes reject_log=yes } 3-COMMENT=-----Enforcing Mode----- 3-CONFIG={ mode=enforcing grant_log=yes reject_log=yes } CONFIG はアクセス制御機能の指定です。以下のカテゴリがあります。 file network capability ipc misc カテゴリを指定した設定は、カテゴリを指定しない設定より優先されます。例えば 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } 0-CONFIG::file={ mode=learning grant_log=yes reject_log=yes } のように指定した場合、 file に関するアクセス制御機能は学習モードに、 それ以外のアクセス制御機能は無効モードに設定されます。 file カテゴリには以下の項目が含まれます。 execute open create unlink mkdir rmdir mkfifo mksock truncate symlink rewrite mkblock mkchar link rename chmod chown chgrp ioctl chroot mount umount pivot_root 項目を指定した設定は、項目を指定しない設定より優先されます。例えば 1-CONFIG::file={ mode=learning grant_log=yes reject_log=yes } 1-CONFIG::file::execute={ mode=enforcing grant_log=yes reject_log=yes } のように指定した場合、プログラムの実行およびドメイン遷移については強制モードに、 それ以外の file に関するアクセス制御機能は学習モードに設定されます。 従来はプログラムの実行可否（およびドメイン遷移）とそれ以外のファイルに対する アクセス（ファイル作成や読み書きなど）可否を MAC_FOR_FILE で指定していたため、 プログラムの実行可否（およびドメイン遷移）とそれ以外のファイルに対するアクセスの モードを個別に設定することができませんでした。しかし、プログラムの実行可否 （およびドメイン遷移）だけを先に強制モードにできるようになったことで、 どのようにドメイン遷移を行わせるかをデザインしてプログラムの実行可否 （およびドメイン遷移）のみを先に確定（強制モードに移行）してから、それ以外の アクセス許可を追加（学習モード）していくことが可能になりました。 そのため、 execute_handler を用いてプログラム実行時のパラメータだけを記録する 用途や、プログラムの実行可否（およびドメイン遷移）だけを制御する用途でも 使えるようになりました。 network カテゴリには以下の項目が含まれます。 inet_udp_bind inet_udp_connect inet_tcp_bind inet_tcp_listen inet_tcp_connect inet_tcp_accept inet_raw_bind inet_raw_connect 例えば 3-CONFIG::network={ mode=enforcing grant_log=yes reject_log=yes } 3-CONFIG::network::inet_tcp_accept={ mode=enforcing grant_log=no reject_log=no } のように指定した場合、 TCP 接続を受け付ける操作に関してはアクセスログを 取得せず、それ以外の操作に関してはアクセスログを取得するという設定になります。 capability カテゴリには以下の項目が含まれます。 inet_tcp_create inet_tcp_listen inet_tcp_connect use_inet_udp use_inet_ip use_route use_packet SYS_MOUNT SYS_UMOUNT SYS_REBOOT SYS_CHROOT SYS_KILL SYS_VHANGUP SYS_TIME SYS_NICE SYS_SETHOSTNAME use_kernel_module create_fifo create_block_dev create_char_dev create_unix_socket SYS_LINK SYS_SYMLINK SYS_RENAME SYS_UNLINK SYS_CHMOD SYS_CHOWN SYS_IOCTL SYS_KEXEC_LOAD SYS_PIVOT_ROOT SYS_PTRACE conceal_mount ipc カテゴリには以下の項目が含まれます。 signal misc カテゴリには以下の項目が含まれます。 env 今日は知世ちゃんの誕生日です。どうぞ TOMOYO の世界をお楽しみください。 :-) From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Wed Sep 9 20:11:14 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Wed, 9 Sep 2009 20:11:14 +0900 Subject: [Tomoyo-dev 1178] =?iso-2022-jp?b?GyRCJUQhPCVrJE5ENEAwJEskRCQkJEYbKEI=?= In-Reply-To: <200909032213.HBG97450.PtUSTZFSNTGPPVPtN@I-love.SAKURA.ne.jp> References: <200909032213.HBG97450.PtUSTZFSNTGPPVPtN@I-love.SAKURA.ne.jp> Message-ID: <200909092011.AGI82374.WNGtEZPSPNPPFtU@I-love.SAKURA.ne.jp> 　熊猫です。 　現在 TOMOYO 1.7.0 向けツールの調整（新しくなった構文への対応など）を 行っています。 　手順書を更新しながら、 http://tomoyo.sourceforge.jp/1.7/tuning.html の手間を 軽減したいと思いました。パターン化を行うために ccs-editpolicy には O コマンドが 提供されていますが、パターンを追加（A）→パターンの行へ移動（↑↓）→パターンに 含まれるものを選択（O）→選択されたものを削除（D）というステップを、複数の ドメインやアクセス許可に対して繰り返すのは面倒です。そこで、一括パターン化を 行えるように ccs-patternize というプログラムも提供しています。 ccs-patternize '/etc/mtab~\$' '/tmp/sh-thd-\$' < /etc/ccs/domain_policy.conf > /etc/ccs/domain_policy.tmp のように実行することでパターンに一致するものを置換します。 特定のドメインだけを対象としたい場合に、わざわざテンポラリファイルに 切り出さなくても実行できるように、 ccs-selectpolicy コマンドを追加しました。 （ revision 3006 ） 　ccs-selectpolicy -r ' /usr/sbin/httpd' < /etc/ccs/domain_policy.conf | ccs-patternize '/etc/mtab~\$' '/tmp/sh-thd-\$' > /etc/ccs/domain_policy.tmp のようにして切り出すことができます。 　今までは ccs-patternize は file_pattern だけしか指定できませんでしたが、 path_group number_group address_group も指定できるように拡張しました。 ccs-patternize 'file_pattern /etc/mtab~\$' 'path_group GROUP1 /tmp/sh-thd-\$' < /etc/ccs/domain_policy.conf > /etc/ccs/domain_policy.tmp のように指定します。パターンが多数ある場合は xargs -d '\n' -a /etc/ccs/exception_policy.conf ccs-patternize < /etc/ccs/domain_policy.conf > /etc/ccs/domain_policy.tmp のように xargs を使うことでファイルを指定できます。 　ccs-patternize で置換後の結果確認には diff を使っていますが、 diff の出力には ドメイン名が含まれないので、どのドメインに対するアクセス許可が置換されたのかを 確認することができません。そこで、（ ccs-loadpolicy に渡せるような） ドメイン名を含んだ差分形式を出力するためのコマンドとして ccs-diffpolicy を 追加しました。 ccs-diffpolicy /etc/ccs/domain_policy.conf /etc/ccs/domain_policy.tmp | less で置換結果を確認して、 ccs-diffpolicy /etc/ccs/domain_policy.conf /etc/ccs/domain_policy.tmp | ccs-loadpolicy -d で反映完了です。 ・・・で、この変更によって少しは手間を軽減できそうでしょうか？ あるいは、もっと改善できそうな点とかありますでしょうか？ 　その他には、 ccs-editpolicy からのセーブ／ロード機能ですね。検討事項としては (1) ccs-editpolicy-agent 経由で操作している場合、 ccs-editpolicy-agent を 　　実行しているマシンに保存したいのか、ローカルマシンに保存したいのかを 　　指定する必要があります。 (2) セーブやロードするときのキー割り当ては < と > が適切でしょうか？ 　　（他のコマンドは指１本で押せますが、 < と > は Shift キーを押しながらなので 　　指１本ではできません。）また、 ccs-savepolicy d と ccs-loadpolicy d と 　　ccs-loadpolicy df とを区別するために < と > 以外にもう１つキー割り当てが 　　必要ではないでしょうか？ (3) ccs-editpolicy から操作する場合、対象をどう指定しますか？現在表示されている 　　画面のポリシーだけを対象（ ccs-savepolicy d や ccs-savepolicy e など）に 　　するのか、全てのポリシーを対象（ ccs-savepolicy edpm ）にするのかを伝える 　　必要があります。 (4) ccs-editpolicy-agent にセーブ／ロード機能を持たせてほしいとのリクエストを 　　受けています。 ccs-editpolicy-agent を実行しているマシンではポリシーの 　　保存場所が /etc/ccs/ ではないケースがあります。ポリシーの保存場所を伝える 　　必要がありますが、どのように指定しますか？ 　　ccs-editpolicy-agent のコマンドラインで指定すればＯＫでしょうか？ 　　（ Android の場合は /data/ パーティション内に存在すればそれを、 　　存在しなければ /system/ パーティション内に存在するものを使うことになると 　　思いますので、優先度の高い順に複数指定することになると思います。） くらいでしょうか？ 　TOMOYO 1.6.5 のリリース時に ccs-tools に追加された、ポリシーファイルを /etc/ccs/\*.base と /etc/ccs/\*.conf に分割して .conf には差分だけを保存する 機能ですが、 Android での経験から、差分だけを保存するという仕様よりも 環境変数 PATH みたいに複数のディレクトリを検索して最初に見つかったファイルを 利用する仕様のほうが実用的であると感じたので、削除しました。 ドメインポリシーの差分だけを抽出したい場合には ccs-diffpolicy をご利用 ください。 　あとは、デモ向けに特定のドメイン以下だけ（例えば " /usr/bin/gnome-terminal" ドメイン以下だけ）を部分表示する機能が 欲しいですか？部分表示をサポートする場合、 initialize_domain のジャンプ先 （「 -> 番号」の指す行）が（表示対象の範囲外となってしまうために）表示 できませんが、どう対処しますか？（例えば（「 -> 番号」）の行で Enter を押すと 部分表示の設定を解除して全体表示に移行するとか？あるいは、全体表示と 部分表示を < と > で切り替えできるようにするとか？） From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Fri Sep 11 01:47:50 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Fri, 11 Sep 2009 01:47:50 +0900 Subject: [Tomoyo-dev 1179] =?iso-2022-jp?b?GyRCOkY1IjtYRGokTkp9SyEkSyREJCQkRhsoQg==?= Message-ID: <200909110147.DBF56279.EFtUNNPPZGWtPPS@I-love.SAKURA.ne.jp> 　熊猫です。 　突然ですが http://sourceforge.jp/projects/tomoyo/lists/archive/users-en/2009-August/000088.html で リクエストされていた再帰指定の方法を思いついたので実装してみました。 （ revision 3012 ） /\{dir\}/ という指定を行うと dir の１回以上の繰り返し（例： /dir/ /dir/dir/ /dir/dir/dir/ /dir/dir/dir/dir/ ）に一致します。 \{ 演算子は /\{ というシーケンスでのみ指定できます。 \} 演算子は \}/ というシーケンスでのみ指定できます。 \{ と \} の間に / を含めることはできません。 幾つか例を示します。 /home/vladap/software/firefox/firefox/\{\*\}/\*.dat /var/www/html/\{\*\-.\*\}/\*.html /var/www/html/\{\*\-.\*\}/public/\*.html /home/kumaneko/SVN/\{\*\-.svn\}/\* /home/kumaneko/SVN/\{\*\}/\$\*/\{\*\}/.svn/entries キーポイントは、 \{ と \} で囲まれたパターンは、パス名の最後の / 以降と 一致することが無いという点です。ユーザは明示的にパス名の最後の / 以降を 指定することが必要です。これは、 /var/www/html/\{\*\} （ /var/www/html/ 以下の 全ファイル）のような、緩すぎる一致をさせないための仕様です。 \{ と \} は /\{ と \}/ という形でのみ使用できるため、 TOMOYO のパス名減算 演算子である \- との競合も回避できています。 利用可能なスタックメモリが少ないカーネル空間で完全な正規表現を実装するのは 無理でしょうし、繰り返し回数まで指定できるようにする必要も無いと思うのですが、 どうでしょう？ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Sep 12 20:35:18 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 12 Sep 2009 20:35:18 +0900 Subject: [Tomoyo-dev 1180] Re: =?iso-2022-jp?b?GyRCOkY1IjtYRGokTkp9SyEkSyREJCQkRhsoQg==?= In-Reply-To: <200909110147.DBF56279.EFtUNNPPZGWtPPS@I-love.SAKURA.ne.jp> References: <200909110147.DBF56279.EFtUNNPPZGWtPPS@I-love.SAKURA.ne.jp> Message-ID: <200909122035.JEA41544.PNNWZFPUSPGEPtt@I-love.SAKURA.ne.jp> 　熊猫＠現在 Twitter 進行中（ http://twitter.com/search?q=%23hbstudy ）です。 　/\{\*\}/ は \* の１回以上の繰り返しですので、 // にはマッチしますが、 / にはマッチしません。よって Toshiharu Harada さんは某所で書きました： >>/home/vladap/software/firefox/firefox/\{\*\}/\*.dat >/home/vladap/software/firefox/firefox/の下にある「なんとか.dat」 /home/vladap/software/firefox/firefox/\*/\*.dat /home/vladap/software/firefox/firefox/\*/\*/\*.dat /home/vladap/software/firefox/firefox/\*/\*/\*/\*.dat /home/vladap/software/firefox/firefox/\*/\*/\*/\*/\*.dat などにマッチします。 /home/vladap/software/firefox/firefox/\*.dat にはマッチしないことに ご注意ください。 >>/var/www/html/\{\*\-.\*\}/\*.html >/var/www/html/の下にある「なんとか.html」 /var/www/html/なんとか.html とか /var/www/html/.svn/\*.html とか /var/www/html/test/.svn/\*.html とかには マッチしないことにご注意ください。 >>/var/www/html/\{\*\-.\*\}/public/\*.html >/var/www/html/の下にある「publicというディレクトリの直下のなんとか.html」 /var/www/html/public/なんとか.html には マッチしないことにご注意ください。 ということで、 http://sourceforge.jp/projects/tomoyo/lists/archive/users-en/2009-September/000099.html に投げましたが、「０回以上の繰り返し」のほうが良いでしょうか？ From from-tomoyo-users ＠ I-love.SAKURA.ne.jp Sun Sep 13 21:20:52 2009 From: from-tomoyo-users ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 13 Sep 2009 21:20:52 +0900 Subject: [Tomoyo-dev 1181] =?iso-2022-jp?b?GyRCOkY1IjtYRGokTkp9SyEkSyREJCQkRhsoQg==?= In-Reply-To: <200909122035.JEA41544.PNNWZFPUSPGEPtt@I-love.SAKURA.ne.jp> References: <200909110147.DBF56279.EFtUNNPPZGWtPPS@I-love.SAKURA.ne.jp> <200909122035.JEA41544.PNNWZFPUSPGEPtt@I-love.SAKURA.ne.jp> Message-ID: <200909132120.BBC12987.NFSPtGPtNSPVZUTPT@I-love.SAKURA.ne.jp> 　熊猫です。 　何度も要望の出ていた「パス名を再帰的に指定する」方法をサポートすることに なりました。大きな変化なので tomoyo-users でも事前にお知らせとご意見募集を 行います。 　現在、 /\{dir\}/ というパターンを "/" + " dir/ の１回以上の繰り返し" に 一致させる方向で進んでいます。例えば、 　allow_read /var/www/html/\{\*\}/\*.html という指定は 　allow_read /var/www/html/\*/\*.html 　allow_read /var/www/html/\*/\*/\*.html 　allow_read /var/www/html/\*/\*/\*/\*.html 　allow_read /var/www/html/\*/\*/\*/\*/\*.html 　allow_read /var/www/html/\*/\*/\*/\*/\*/\*.html 　（以下省略） のように機能します。また、 path_group SVN_FILES /home/kumaneko/SVN/\{\*\-.svn\}/\* という指定は 　path_group SVN_FILES /home/kumaneko/SVN/\*\-.svn/\* 　path_group SVN_FILES /home/kumaneko/SVN/\*\-.svn/\*\-.svn/\* 　path_group SVN_FILES /home/kumaneko/SVN/\*\-.svn/\*\-.svn/\*\-.svn/\* 　path_group SVN_FILES /home/kumaneko/SVN/\*\-.svn/\*\-.svn/\*\-.svn/\*\-.svn/\* 　path_group SVN_FILES /home/kumaneko/SVN/\*\-.svn/\*\-.svn/\*\-.svn/\*\-.svn/\*\-.svn/\* 　（以下省略） のように機能します。 　しかし、１回以上の繰り返しなので、 　allow_read /var/www/html/\*.html や 　path_group SVN_FILES /home/kumaneko/SVN/\* のようには機能しません。そのため、 　/var/www/html/ 以下の全ての \*.html を読み込みモードでオープンしてよい という指定を行いたい場合には 　allow_read /var/www/html/\*.html 　allow_read /var/www/html/\{\*\}/\*.html のように２行に分けて指定する必要があります。 行数を減らすために /var/www/html/\{\*\}/\*.html が /var/www/html/\*.html （ \*/ の０回繰り返し）を包含してほしいと考えている方もいるようです。 　もし、０回以上の繰り返しにした場合、 /tmp/ 以下の全てのディレクトリを 指定するつもりで 　allow_rmdir /tmp/\{\*\}/ のように指定してしまうと /tmp/ ディレクトリ自身も含まれてしまうことになり、 期待していたものよりも広い許可を与えてしまう危険があります。 　０回以上の繰り返しにした場合でも、 /\{dir\}/ というパターンで終わる指定を 禁止するという制約を付ければ、明示的に 　allow_rmdir /tmp/\{\*\}/\*/ のような指定を行うことになるため、 /tmp/ ディレクトリ自身が含まれてしまうことを 回避できるかと思います。 　そこで、ご意見募集です。 /\{dir\}/ というパターンは (1) "/" + " dir/ の１回以上の繰り返し" に一致させる (2) "/" + " dir/ の０回以上の繰り返し" に一致させる (3) "/" + " dir/ の０回以上の繰り返し" に一致させるが、 /\{dir\}/ という 　　パターンで終わる指定を禁止するという制約を付ける のどれが良いと思いますか？ From yocto1 ＠ gmail.com Mon Sep 14 00:37:39 2009 From: yocto1 ＠ gmail.com (yocto) Date: Mon, 14 Sep 2009 00:37:39 +0900 Subject: [Tomoyo-dev 1182] Re: =?iso-2022-jp?b?GyRCOkY1IjtYRGokTkp9SyEkSyREJCQkRhsoQg==?= In-Reply-To: <200909132120.BBC12987.NFSPtGPtNSPVZUTPT@I-love.SAKURA.ne.jp> References: <200909110147.DBF56279.EFtUNNPPZGWtPPS@I-love.SAKURA.ne.jp> <200909122035.JEA41544.PNNWZFPUSPGEPtt@I-love.SAKURA.ne.jp> <200909132120.BBC12987.NFSPtGPtNSPVZUTPT@I-love.SAKURA.ne.jp> Message-ID: <8f3c749a0909130837l23a9c7ah14dd3de68e705f73@mail.gmail.com> クスノです。 (1)に1票 2009年9月13日21:20 Tetsuo Handa : > 　熊猫です。 ... > そこで、ご意見募集です。 /\{dir\}/ というパターンは > > (1) "/" + " dir/ の１回以上の繰り返し" に一致させる > > (2) "/" + " dir/ の０回以上の繰り返し" に一致させる > > (3) "/" + " dir/ の０回以上の繰り返し" に一致させるが、 /\{dir\}/ という > パターンで終わる指定を禁止するという制約を付ける > > のどれが良いと思いますか？ From hiroshi.shinji ＠ gmail.com Mon Sep 14 01:58:36 2009 From: hiroshi.shinji ＠ gmail.com (Hiroshi Shinji) Date: Mon, 14 Sep 2009 01:58:36 +0900 Subject: [Tomoyo-dev 1183] Re: =?iso-2022-jp?b?GyRCOkY1IjtYRGokTkp9SyEkSyREJCQkRhsoQg==?= In-Reply-To: <200909132120.BBC12987.NFSPtGPtNSPVZUTPT@I-love.SAKURA.ne.jp> References: <200909110147.DBF56279.EFtUNNPPZGWtPPS@I-love.SAKURA.ne.jp> <200909122035.JEA41544.PNNWZFPUSPGEPtt@I-love.SAKURA.ne.jp> <200909132120.BBC12987.NFSPtGPtNSPVZUTPT@I-love.SAKURA.ne.jp> Message-ID: 宍道です。 > 何度も要望の出ていた「パス名を再帰的に指定する」方法をサポートすることに > なりました。大きな変化なので tomoyo-users でも事前にお知らせとご意見募集を > 行います。 パス名を再帰的に指定出きるのは、便利でよいと思うのですが、 パフォーマンス的に、どの程度影響しそうですか？ （そんなに影響しない？） (1)〜(3)の選択では、私は (1) です。 2009年9月13日21:20 Tetsuo Handa : > 　熊猫です。 > > 何度も要望の出ていた「パス名を再帰的に指定する」方法をサポートすることに > なりました。大きな変化なので tomoyo-users でも事前にお知らせとご意見募集を > 行います。 > > > > 現在、 /\{dir\}/ というパターンを "/" + " dir/ の１回以上の繰り返し" に > 一致させる方向で進んでいます。例えば、 > > allow_read /var/www/html/\{\*\}/\*.html > > という指定は > > allow_read /var/www/html/\*/\*.html > allow_read /var/www/html/\*/\*/\*.html > allow_read /var/www/html/\*/\*/\*/\*.html > allow_read /var/www/html/\*/\*/\*/\*/\*.html > allow_read /var/www/html/\*/\*/\*/\*/\*/\*.html > （以下省略） > > のように機能します。また、 > > path_group SVN_FILES /home/kumaneko/SVN/\{\*\-.svn\}/\* > > という指定は > > path_group SVN_FILES /home/kumaneko/SVN/\*\-.svn/\* > path_group SVN_FILES /home/kumaneko/SVN/\*\-.svn/\*\-.svn/\* > path_group SVN_FILES /home/kumaneko/SVN/\*\-.svn/\*\-.svn/\*\-.svn/\* > path_group SVN_FILES /home/kumaneko/SVN/\*\-.svn/\*\-.svn/\*\-.svn/\*\-.svn/\* > path_group SVN_FILES /home/kumaneko/SVN/\*\-.svn/\*\-.svn/\*\-.svn/\*\-.svn/\*\-.svn/\* > （以下省略） > > のように機能します。 > > > > しかし、１回以上の繰り返しなので、 > > allow_read /var/www/html/\*.html > > や > > path_group SVN_FILES /home/kumaneko/SVN/\* > > のようには機能しません。そのため、 > > /var/www/html/ 以下の全ての \*.html を読み込みモードでオープンしてよい > > という指定を行いたい場合には > > allow_read /var/www/html/\*.html > allow_read /var/www/html/\{\*\}/\*.html > > のように２行に分けて指定する必要があります。 > 行数を減らすために /var/www/html/\{\*\}/\*.html が /var/www/html/\*.html > （ \*/ の０回繰り返し）を包含してほしいと考えている方もいるようです。 > > > > もし、０回以上の繰り返しにした場合、 /tmp/ 以下の全てのディレクトリを > 指定するつもりで > > allow_rmdir /tmp/\{\*\}/ > > のように指定してしまうと /tmp/ ディレクトリ自身も含まれてしまうことになり、 > 期待していたものよりも広い許可を与えてしまう危険があります。 > > ０回以上の繰り返しにした場合でも、 /\{dir\}/ というパターンで終わる指定を > 禁止するという制約を付ければ、明示的に > > allow_rmdir /tmp/\{\*\}/\*/ > > のような指定を行うことになるため、 /tmp/ ディレクトリ自身が含まれてしまうことを > 回避できるかと思います。 > > > > そこで、ご意見募集です。 /\{dir\}/ というパターンは > > (1) "/" + " dir/ の１回以上の繰り返し" に一致させる > > (2) "/" + " dir/ の０回以上の繰り返し" に一致させる > > (3) "/" + " dir/ の０回以上の繰り返し" に一致させるが、 /\{dir\}/ という > パターンで終わる指定を禁止するという制約を付ける > > のどれが良いと思いますか？ > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- 宍道 洋 hiroshi.shinji ＠ gmail.com http://d.hatena.ne.jp/hshinji/ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Mon Sep 14 11:26:40 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 14 Sep 2009 11:26:40 +0900 Subject: [Tomoyo-dev 1184] Re: =?iso-2022-jp?b?GyRCOkY1IjtYRGokTkp9SyEkSyREJCQkRhsoQg==?= In-Reply-To: References: <200909110147.DBF56279.EFtUNNPPZGWtPPS@I-love.SAKURA.ne.jp> <200909122035.JEA41544.PNNWZFPUSPGEPtt@I-love.SAKURA.ne.jp> <200909132120.BBC12987.NFSPtGPtNSPVZUTPT@I-love.SAKURA.ne.jp> Message-ID: <200909140226.n8E2QeEq086001@www262.sakura.ne.jp> 　熊猫です。 Hiroshi Shinji さんは書きました： > パス名を再帰的に指定出きるのは、便利でよいと思うのですが、 > パフォーマンス的に、どの程度影響しそうですか？ > （そんなに影響しない？） パターンを含まない文字列同士の比較にはハッシュ値の比較および strcmp() を 使うのでまったく影響しません。 今まではパス名の深さ（文字列中の / の数）による比較を行っていましたが、 /\{dir\}/ を導入したことでパス名の深さによる比較が不可能になりました。 そのため、今まではパス名の深さ比較だけで一致する可能性が無い場合には 一致しないと判断していた処理が削られ、実際に比較を行うようになります。 これは、パフォーマンスに影響するかもしれません。 文字列の先頭から最初のパターンが出現するまでは strncmp() を使うので まったく影響しません。また、文字列の先頭からパターンが使われること （ /\*/\*/\*/\*/\*.html のような指定）は稀なので /bin/true と /var/www/html/\{\*\}/\*.html のような比較は strncmp() により この時点で一致しないと判断できるため、パス名の深さによる比較が不可能に なったことによるパフォーマンスへの影響を減らすことができます。 最初のパターンから文字列の末尾までは /\{dir\}/ に一致しない限り 従来とほぼ同様ですので、パフォーマンスへの影響はほとんどありません。 /\{dir\}/ に一致した場合は文字列の末尾までの / の数に応じてパフォーマンスに 影響します。 実際にどの程度の影響があるかは測定プログラムを使わないと判りません。 @@ -820,6 +815,68 @@ } /** + * ccs_path_matches_pattern2 - Do pathname pattern matching. + * + * @f: The start of string to check. + * @p: The start of pattern to compare. + * + * Returns true if @f matches @p, false otherwise. + */ +static bool ccs_path_matches_pattern2(const char *f, const char *p) +{ + const char *f_delimiter; + const char *p_delimiter; + while (*f && *p) { + f_delimiter = strchr(f, '/'); + if (!f_delimiter) + f_delimiter = strchr(f, '\0'); + p_delimiter = strchr(p, '/'); + if (!p_delimiter) + p_delimiter = strchr(p, '\0'); + if (*p == '\\' && *(p + 1) == '{') + goto recursive; + if (!ccs_file_matches_pattern(f, f_delimiter, p, p_delimiter)) + return false; + f = f_delimiter; + if (*f) + f++; + p = p_delimiter; + if (*p) + p++; + } + /* Ignore trailing "\*" and "\@" in @pattern. */ + while (*p == '\\' && + (*(p + 1) == '*' || *(p + 1) == '@')) + p += 2; + return !*f && !*p; + recursive: + /* + * The "\{" pattern is permitted only after '/' character. + * This guarantees that below "*(p - 1)" is safe. + * Also, the "\}" pattern is permitted only before '/' character + * so that "\{" + "\}" pair will not break the "\-" operator. + */ + if (*(p - 1) != '/' || p_delimiter <= p + 3 || *p_delimiter != '/' || + *(p_delimiter - 1) != '}' || *(p_delimiter - 2) != '\\') + return false; /* Bad pattern. */ + do { + /* Compare current component with pattern. */ + if (!ccs_file_matches_pattern(f, f_delimiter, p + 2, + p_delimiter - 2)) + break; + /* Proceed to next component. */ + f = f_delimiter; + if (*f) + f++; + /* Continue comparison. */ + if (ccs_path_matches_pattern2(f, p_delimiter + 1)) + return true; + f_delimiter = strchr(f, '/'); + } while (f_delimiter); + return false; /* Not matched. */ +} + +/** * ccs_path_matches_pattern - Check whether the given filename matches the given pattern. * @filename: The filename to check. * @pattern: The pattern to compare. @@ -829,16 +886,20 @@ * The following patterns are available. * \\ \ itself. * \ooo Octal representation of a byte. - * \* More than or equals to 0 character other than '/'. - * \@ More than or equals to 0 character other than '/' or '.'. + * \* Zero or more repetitions of characters other than '/'. + * \@ Zero or more repetitions of characters other than '/' or '.'. * \? 1 byte character other than '/'. - * \$ More than or equals to 1 decimal digit. + * \$ One or more repetitions of decimal digits. * \+ 1 decimal digit. - * \X More than or equals to 1 hexadecimal digit. + * \X One or more repetitions of hexadecimal digits. * \x 1 hexadecimal digit. - * \A More than or equals to 1 alphabet character. + * \A One or more repetitions of alphabet characters. * \a 1 alphabet character. + * * \- Subtraction operator. + * + * /\{dir\}/ One or more repetitions of dir (e.g. /dir/ /dir/dir/ + * /dir/dir/dir/ ). */ bool ccs_path_matches_pattern(const struct ccs_path_info *filename, const struct ccs_path_info *pattern) @@ -853,36 +914,15 @@ /* If @pattern doesn't contain pattern, I can use strcmp(). */ if (!pattern->is_patterned) return !ccs_pathcmp(filename, pattern); - /* Don't compare if the number of '/' differs. */ - if (filename->depth != pattern->depth) + /* Don't compare directory and non-directory. */ + if (filename->is_dir != pattern->is_dir) return false; /* Compare the initial length without patterns. */ if (strncmp(f, p, len)) return false; f += len; p += len; - /* Main loop. Compare each directory component. */ - while (*f && *p) { - const char *f_delimiter = strchr(f, '/'); - const char *p_delimiter = strchr(p, '/'); - if (!f_delimiter) - f_delimiter = f + strlen(f); - if (!p_delimiter) - p_delimiter = p + strlen(p); - if (!ccs_file_matches_pattern(f, f_delimiter, p, p_delimiter)) - return false; - f = f_delimiter; - if (*f) - f++; - p = p_delimiter; - if (*p) - p++; - } - /* Ignore trailing "\*" and "\@" in @pattern. */ - while (*p == '\\' && - (*(p + 1) == '*' || *(p + 1) == '@')) - p += 2; - return !*f && !*p; + return ccs_path_matches_pattern2(f, p); } /** From henrich ＠ debian.or.jp Tue Sep 15 14:05:39 2009 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Tue, 15 Sep 2009 14:05:39 +0900 Subject: [Tomoyo-dev 1185] =?iso-2022-jp?b?Mi4yIC0+IDIuMyAoUmU6IBskQiVXJW0lVSUhJSQlayROGyhC?= =?iso-2022-jp?b?GyRCO1hEakp9SyEkTkpROTkkSyREJCQkRhsoQg==?= In-Reply-To: <200908280145.n7S1juIm074916@www262.sakura.ne.jp> References: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> <20090828045736.0006bb4f.henrich@debian.or.jp> <200908280145.n7S1juIm074916@www262.sakura.ne.jp> Message-ID: <20090915140539.27ccc238.henrich@debian.or.jp> On Fri, 28 Aug 2009 10:45:56 +0900 Tetsuo Handa wrote: > > 　　-> 2.2 系を別に用意するのならば 1.6.8 系は 1.7 にして > > 　　　おかないと3つもパッケージが存在して色々コストが嵩むので > 2.3 は 1.7 の仕様の内、ＬＳＭで実現できる範囲で、なおかつメインラインからの > 了承が得られた機能が反映される予定です。（ 1.6 -> 1.7 と同様に構文の見直しが > 発生するので） 2.3 でも 2.2 からの migration は不可能になります。ですから、 > 2.x 用のツールパッケージに関しても 1.x 用のツールパッケージと同じことを > 考えておく必要がありますね。 　2.3 がリリースされるのはいつ頃になるのでしょうか？ 　1.6 がサポートされ続ける限りは 1.6 でプロファイルを作ったユーザは 1.6 を 　使いつづけたいでしょうし、1.7 は互換性がないので 1.6 とは別に作成が必要です。 　2.2 系を作ったとしたら 2.3 系も同様に作成しないとまずくなるでしょうから、 　tomoyo だけで6パッケージも存在してしまうことになってメンテナンスコストが 　大きいです。 　1.6 と 1.7 の併存は仕方がないとして、2 系は1つにまとめたいのが私の希望です。 　2.3 が出てから入れるとしてその時期はいつ頃になりそうのでしょうか。あまり 　遠い将来でないのならそれを待とうと思います。 -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane From henrich ＠ debian.or.jp Tue Sep 15 14:27:36 2009 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Tue, 15 Sep 2009 14:27:36 +0900 Subject: [Tomoyo-dev 1186] Re: =?iso-2022-jp?b?GyRCJUklLSVlJWElcyVITmAkTiUkJXMlOSVIITwbKEI=?= =?iso-2022-jp?b?GyRCJWswTENWGyhC?= In-Reply-To: <20080726193134.dee7083e.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> <200805100231.EBH30259.EPPtNPtZUSPGWFN@I-love.SAKURA.ne.jp> <20080510093717.51edf4bc.henrich@debian.or.jp> <20080726193134.dee7083e.henrich@debian.or.jp> Message-ID: <20090915142736.7b0177fa.henrich@debian.or.jp> On Sat, 26 Jul 2008 19:31:34 +0900 Hideki Yamane wrote: > > On Sat, 10 May 2008 02:31:34 +0900 > > Tetsuo Handa wrote: > > > > 　・インストールするものとして（バイナリとして） COPYING ファイルは、必要ではない。 > > > ソースパッケージからであれバイナリパッケージからであれインストールする際に一緒にコピーされないと > > > ユーザの目に留まらないと思うので、一緒にコピーされるようにしたいです。 > > > > 　この点が理解できません。 > > 　そのためにシステムとして不適当なことをやるのは構わない (FHS は無視)、 > > 　ということですか？ > > 　すいません、やはりこの点が細かいですが気になります。 > 　カーネルのコーディングでも規約があるように、システムのファイル配置に > 　も規約 (FHS) があります。それは遵守して頂きたいです。 > > 　自分がシステム管理者だったとしたら、様々な違い（Linux distro /*BSD など） > 　があるにしても、設定ファイルであれば /etc にあるのだと思うし、実行ファイル > 　は /bin などにあるのだろうな、と考えます。なのに、今回の COPYING ファイル > 　は全然普遍的では無い位置に配置される。 > 　 > 　ディレクトリを掘りたくない、だけでは規約を守らない理由としては弱い > 　と思いますがいかがでしょうか？ 　未だに上記が直っていません。2.2 の Makefile をみると cp -af --remove-destination README.tomoyo COPYING.tomoyo $(INSTALLDIR)/usr/lib/tomoyo/ 　です。　 cp -af --remove-destination README.tomoyo COPYING.tomoyo $(INSTALLDIR)/usr/share/doc/tomoyo/ 　で無いのは何故ですか？ /usr/lib は /usr/lib Contains dynamic libraries and support static files for the executables at /usr/bin and /usr/sbin. You can create a subdirectory like /usr/lib/myproduct to contain your helper files, or dynamic libraries that will be accessed only by your Software, without user intervention. A subdirectory here can be used as a container for plugins and extensions. 　と明示的に定義されています。dynamic libraries や support static files ではない 　ファイルをおくのは不適当です。 -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Tue Sep 15 22:57:23 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 15 Sep 2009 22:57:23 +0900 Subject: [Tomoyo-dev 1187] Re: =?iso-2022-jp?b?Mi4yIC0+IDIuMyAoUmU6IBskQiVXJW0lVSUhJSQbKEI=?= =?iso-2022-jp?b?GyRCJWskTjtYRGpKfUshJE5KUTk5JEskRCQkJEYbKEI=?= In-Reply-To: <20090915140539.27ccc238.henrich@debian.or.jp> References: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> <20090828045736.0006bb4f.henrich@debian.or.jp> <200908280145.n7S1juIm074916@www262.sakura.ne.jp> <20090915140539.27ccc238.henrich@debian.or.jp> Message-ID: <200909152257.AJF52666.PPSWUtPFNtEPZGN@I-love.SAKURA.ne.jp> 　熊猫です。 Hideki Yamane さんは書きました： > 　2.3 がリリースされるのはいつ頃になるのでしょうか？ 2.x はマージされた時点でリリース時期が確定します。マージするかどうかを 決めるのは熊猫ではないのでいつになるのかは知りません。半年後かもしれませんし、 何年経ってもリリースされないかもしれません。 > 　2.2 系を作ったとしたら 2.3 系も同様に作成しないとまずくなるでしょうから、 > 　tomoyo だけで6パッケージも存在してしまうことになってメンテナンスコストが > 　大きいです。 > > 　1.6 と 1.7 の併存は仕方がないとして、2 系は1つにまとめたいのが私の希望です。 2.2 → 2.3 は 1.6 → 1.7 と同様の構造変化ですから、 2.2 用と 2.3 用とを１個に まとめるつもりはありません。 2.3 で 1.7 のほとんどの機能を取り込めれば、 1.7 用と 2.3 用とを１個にまとめることならできるでしょう。しかし、 2.3 で どれくらい取り込めるかは未知数です。 > 　2.3 が出てから入れるとしてその時期はいつ頃になりそうのでしょうか。あまり > 　遠い将来でないのならそれを待とうと思います。 2.x の内容はメインラインカーネルのバージョンに依存していますから、 今後 2.6.30 や 2.6.31 に TOMOYO の機能が追加されることはなく、従って 2.2 用の ツールの変更が必要になることも起こりません。まぁ、 2.3 が出るまでは 2.2 用の ツールのバグフィックスを行うことはあるかもしれませんが、 2.3 が出たら 2.2 は 放置されるようになり、 2.4 が出たら 2.3 は放置されるようになるでしょう。 パッケージの数がＮ個に増えてもメンテナンスコストがＮ倍になるようなものでは 無いと思います。作業量ではなくパッケージの数が増えるのが嫌なら、 2.3 が出たら 2.2 を削除してもいいと思います。 1.6 のサポート期間が終了したら 1.6 を削除して 1.7 だけにしてもいいと思います。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Tue Sep 15 23:01:40 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 15 Sep 2009 23:01:40 +0900 Subject: [Tomoyo-dev 1188] Re: =?iso-2022-jp?b?GyRCJUklLSVlJWElcyVITmAkTiUkJXMlOSVIITwbKEI=?= =?iso-2022-jp?b?GyRCJWswTENWGyhC?= In-Reply-To: <20090915142736.7b0177fa.henrich@debian.or.jp> References: <20080510015324.b8b23ba5.henrich@debian.or.jp> <200805100231.EBH30259.EPPtNPtZUSPGWFN@I-love.SAKURA.ne.jp> <20080510093717.51edf4bc.henrich@debian.or.jp> <20080726193134.dee7083e.henrich@debian.or.jp> <20090915142736.7b0177fa.henrich@debian.or.jp> Message-ID: <200909152301.JCE86932.PFWENSPZPtPNtUG@I-love.SAKURA.ne.jp> 　熊猫です。 Hideki Yamane さんは書きました： > 　未だに上記が直っていません。2.2 の Makefile をみると 1.6 の間は変更しないと決めており、 2.2 は 1.6 を sed -e 's/ccs/tomoyo/g' しただけのものです。 2.2 を直すつもりはありません。 From nabeken ＠ tknetworks.org Wed Sep 16 00:14:58 2009 From: nabeken ＠ tknetworks.org (TANABE Ken-ichi) Date: Wed, 16 Sep 2009 00:14:58 +0900 Subject: [Tomoyo-dev 1189] Re: =?iso-2022-jp?b?GyRCJUklLSVlJWElcyVITmAkTiUkJXMlOSVIITwbKEI=?= =?iso-2022-jp?b?GyRCJWswTENWGyhC?= In-Reply-To: <20090915142736.7b0177fa.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> <200805100231.EBH30259.EPPtNPtZUSPGWFN@I-love.SAKURA.ne.jp> <20080510093717.51edf4bc.henrich@debian.or.jp> <20080726193134.dee7083e.henrich@debian.or.jp> <20090915142736.7b0177fa.henrich@debian.or.jp> Message-ID: <111721cf0909150814g3b9b0837l3f799b25e43c7d4@mail.gmail.com> On Tuesday, September 15, 2009, Hideki Yamane wrote: > On Sat, 26 Jul 2008 19:31:34 +0900 > Hideki Yamane wrote: >> > On Sat, 10 May 2008 02:31:34 +0900 >> > Tetsuo Handa wrote: >> > > > ・インストールするものとして（バイナリとして） COPYING ファイルは、必要ではない。 >> > > ソースパッケージからであれバイナリパッケージからであれインストールする際に一緒にコピーされないと >> > > ユーザの目に留まらないと思うので、一緒にコピーされるようにしたいです。 >> > >> > この点が理解できません。 >> > そのためにシステムとして不適当なことをやるのは構わない (FHS は無視)、 >> > ということですか？ >> >> すいません、やはりこの点が細かいですが気になります。 >> カーネルのコーディングでも規約があるように、システムのファイル配置に >> も規約 (FHS) があります。それは遵守して頂きたいです。 >> >> 自分がシステム管理者だったとしたら、様々な違い（Linux distro /*BSD など） >> があるにしても、設定ファイルであれば /etc にあるのだと思うし、実行ファイル >> は /bin などにあるのだろうな、と考えます。なのに、今回の COPYING ファイル >> は全然普遍的では無い位置に配置される。 >> >> ディレクトリを掘りたくない、だけでは規約を守らない理由としては弱い >> と思いますがいかがでしょうか？ > > 未だに上記が直っていません。2.2 の Makefile をみると > > cp -af --remove-destination README.tomoyo COPYING.tomoyo $(INSTALLDIR)/usr/lib/tomoyo/ > > です。 > cp -af --remove-destination README.tomoyo COPYING.tomoyo $(INSTALLDIR)/usr/share/doc/tomoyo/ > > で無いのは何故ですか？ /usr/lib は > > /usr/lib > > Contains dynamic libraries and support static files for the executables at /usr/bin and /usr/sbin. You can create a subdirectory like /usr/lib/myproduct to contain your helper files, or dynamic libraries that will be accessed only by your Software, without user intervention. A subdirectory here can be used as a container for plugins and extensions. > > と明示的に定義されています。dynamic libraries や support static files ではない > ファイルをおくのは不適当です。 > > > -- > Regards, > > Hideki Yamane henrich @ http://debian.or.jp/iijmio-mail.jp > http://wiki.debian.org/HidekiYamane > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- TANABE Ken-ichi / nabeken Mailto: nabeken ＠ tknetworks.org / gmail.com / gentoo.gr.jp From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Wed Sep 30 02:30:58 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Wed, 30 Sep 2009 02:30:58 +0900 Subject: [Tomoyo-dev 1190] =?iso-2022-jp?b?GyRCJWAhPCVTITwkTiVVJSElJCVrN0E8MCRLJEQkJCRGGyhC?= Message-ID: <200909300230.HIH51027.tNWGUPPZFSNEPPt@I-love.SAKURA.ne.jp> 　熊猫です。 　ポリシー違反時にスリープさせる機能のデモ動画を作ってみました。 http://tomoyo.sourceforge.jp/incoming/sleep-penalty.avi ↑は VMware のムービーキャプチャ機能で撮影したものですが、 それだと VMware Codec をインストールしないと再生できないため、 気軽に観てもらうのが難しそうです。 ↓は CyberLink PowerDirector を使って Windows Media 形式に変換したものです。 http://tomoyo.sourceforge.jp/incoming/sleep-penalty.wmv Windows 環境なら問題ないと思いますが、デスクトップ環境がインストールされた Linux なら普通に Windows Media 形式を再生できるものなんでしょうか？ むしろ、 YouTube に投稿してそこへリンクを張る方が良いですかねぇ？ （ＬＫＭＬの読者など海外のユーザも観れることを重視したいので、 アカウントを作らないと観れないような投稿サイトは考えていません。） From haradats ＠ nttdata.co.jp Wed Sep 30 10:32:13 2009 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Wed, 30 Sep 2009 10:32:13 +0900 Subject: [Tomoyo-dev 1191] Re: =?iso-2022-jp?b?GyRCJWAhPCVTITwkTiVVJSElJCVrN0E8MCRLJEQbKEI=?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: <200909300230.HIH51027.tNWGUPPZFSNEPPt@I-love.SAKURA.ne.jp> References: <200909300230.HIH51027.tNWGUPPZFSNEPPt@I-love.SAKURA.ne.jp> Message-ID: <4AC2B51D.90903@nttdata.co.jp> 原田です。おはようございます。 On 9/30/2009 2:30 AM, Tetsuo Handa wrote: > 　熊猫です。 > > 　ポリシー違反時にスリープさせる機能のデモ動画を作ってみました。 > > http://tomoyo.sourceforge.jp/incoming/sleep-penalty.avi > ↑は VMware のムービーキャプチャ機能で撮影したものですが、 > それだと VMware Codec をインストールしないと再生できないため、 > 気軽に観てもらうのが難しそうです。 > > ↓は CyberLink PowerDirector を使って Windows Media 形式に変換したものです。 > http://tomoyo.sourceforge.jp/incoming/sleep-penalty.wmv > Windows 環境なら問題ないと思いますが、デスクトップ環境がインストールされた > Linux なら普通に Windows Media 形式を再生できるものなんでしょうか？ > > むしろ、 YouTube に投稿してそこへリンクを張る方が良いですかねぇ？ > （ＬＫＭＬの読者など海外のユーザも観れることを重視したいので、 > アカウントを作らないと観れないような投稿サイトは考えていません。） もうひとつの選択肢として、Linux Foundationのビデオサイトがあります。 登録するにはアカウントが必要ですが、参照する人は登録は不要です。 サイズがやや制限がきついかもしれません。 http://video.linuxfoundation.org/ -- 原田季栄 (Toshiharu Harada) haradats at nttdata.co.jp