| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
Linux 3.4 では、 call_usermodehelper() の引数で指定されている UMH_* 定数の値が変更されています。 UMH_* 定数の代わりにハードコードされた整数を指定しているソースコードは、 Linux 3.4 以降では期待通りに動かなくなります。
現時点では、この修正は Ubuntu にバックポートされています。この修正は他のいくつかのディストリビューションにもバックポートされることが予想されます。
CentOS 6.3 等で call_usermodehelper() を含むコードを使用する場合、 UMH_* 定数を使用するように修正されているかどうか確認するようにしてください。
一例として、 DRBD モジュールでは call_usermodehelper() でハードコードされた整数を指定していたため、バグ報告が出ています。
https://bugs.launchpad.net/ubuntu/+source/drbd8/+bug/1000355
Linux にあまり関係ない話ですが、 Windows 版だけでなく Linux 版でも再現できるバグだったので、ここに載せておきます。
Thunderbird で受信したメールを整理しようとしてフォルダを作成していた時に、 Thunderbird では受信したメールを保存するフォルダの名前が「受信トレイ」と表示されていたので、「それなら Inbox という名前のフォルダを作成しても大丈夫だろう。もし駄目ならエラーメッセージが表示されて作成できないようになっているだろうから。」と思って、 Inbox というフォルダ名を指定したところ、既に存在する Inbox フォルダの内容が消滅してしまうという恐ろしいバグを踏んでしまいました。（証拠動画： http://www.youtube.com/watch?v=No3lyZNk9Hc ）
https://bugzilla.mozilla.org/show_bug.cgi?id=749909 にて進行中ですが、その中にナレッジベースへのリンクが登場したので、貼っておきます。
http://kb.mozillazine.org/Disappearing_mail
こういう情報は事前に知っておかないと間に合わないでしょうから・・・今回のバグには無力そうな気がしますが・・・。
近頃のディストリビューションで採用されているバージョンの tail コマンドは inotify を使っているため、環境によっては tail -f が希望通りに機能しないことがあるようです。 Ubuntu 12.04 の LiveCD から tail -f を試してみたのですが、動きませんでした。
| # tail -f /var/log/tomoyo/reject_000.txt /var/log/tomoyo/reject_001.txt /var/log/tomoyo/reject_002.txt /var/log/tomoyo/reject_003.txt |
strace で確認すると、特定のファイルディスクリプタの読み込みでブロックしていることが判ります。
|
# strace -p `pidof tail` Process 4418 attached - interrupt to quit read(7,^C <unfinished ...> Process 4418 detached |
ls で確認すると、そのファイルとは anon_inode:inotify であることが判ります。
|
# ls -l /proc/`pidof tail`/fd/ total 0 lrwx------ 1 root root 64 May 2 11:40 0 -> /dev/pts/0 lrwx------ 1 root root 64 May 2 11:40 1 -> /dev/pts/0 lrwx------ 1 root root 64 May 2 11:40 2 -> /dev/pts/0 lr-x------ 1 root root 64 May 2 11:40 3 -> /var/log/tomoyo/reject_000.log lr-x------ 1 root root 64 May 2 11:40 4 -> /var/log/tomoyo/reject_001.log lr-x------ 1 root root 64 May 2 11:40 5 -> /var/log/tomoyo/reject_002.log lr-x------ 1 root root 64 May 2 11:41 6 -> /var/log/tomoyo/reject_003.log lr-x------ 1 root root 64 May 2 11:41 7 -> anon_inode:inotify |
inotify を使わせないようにするには、 ---disable-inotify という隠しオプションを使います。 - が３つ連続していることに注意してください。
| # tail ---disable-inotify -f /var/log/tomoyo/reject_000.txt /var/log/tomoyo/reject_001.txt /var/log/tomoyo/reject_002.txt /var/log/tomoyo/reject_003.txt |
CentOS 4 は EOL を迎えたわけですが、既にミラーサーバ上から消滅しているので、 yum 設定の更新が必要です。
|
# yum -y update Setting up Update Process Setting up repositories not using ftp, http[s], or file for repos, skipping - 4 is not a valid release or hasnt been released yet Cannot find a valid baseurl for repo: update Error: Cannot find a valid baseurl for repo: update |
具体的には、 baseurl 行にサーバとして vault.centos.org を指定します。
| # sed -i -e 's/^mirrorlist=/#mirrorlist=/' -e 's/^#baseurl=/baseurl=/' -e 's@mirror.centos.org/centos@vault.centos.org@' -e 's/$releasever/4.9/' -- /etc/yum.repos.d/CentOS-Base.repo |
最初の報告から１ヶ月経ったけどまだ何の反応も無いので、犠牲者をこれ以上増やさないようにするために、先に周知します。
lmbench パッケージには、プログラム実行に要する遅延時間を測定する lat_proc というプログラムが入っていますが、 Debian/Ubuntu の lmbench-3.0-a9 をパッケージでインストールした場合には正しい結果が得られません。
これは、存在しない /var/tmp/lmbench/hello というプログラムを lat_proc が実行しようとするため、 execve() が失敗してしまうことが原因です。（失敗してもエラーメッセージ１つ出さないという作りはどうかと思いますが。（汗））
TOMOYO で解析すると、 sh -c を実行しているのに hello プログラムのためのドメインが作成されていないことが確認できます。
43: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lmbench
44: 0 /bin/cp
45: 0 /bin/date
46: 0 /bin/hostname
47: 0 /bin/mkdir
48: 0 /bin/mount
49: 0 /bin/netstat
50: 0 /bin/rm
51: 0 /bin/sleep
52: 0 /bin/sync
53: 0 /bin/tar
54: 0 /bin/uname
55: 0 /sbin/ifconfig
56: 0 /usr/bin/awk
57: 0 /usr/bin/expr
58: 0 /usr/bin/touch
59: 0 /usr/bin/uptime
60: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_file_rd
61: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_mem
62: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_mmap_rd
63: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_pipe
64: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_tcp
65: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/bw_unix
66: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_connect
67: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_ctx
68: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_fs
69: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_http
70: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_mmap
71: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_pagefault
72: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_pipe
73: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_proc
74: 0 /bin/sh
*** ↑ hello プログラムのドメインが存在しない ***
75: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_rpc
76: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_select
77: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_sig
78: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_syscall
79: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_tcp
80: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_udp
81: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lat_unix
82: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lmdd
83: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/lmhttp
84: 0 /usr/lib/lmbench/bin/i686-pc-linux-gnu/msleep
85: 0 /usr/lib/lmbench/scripts/os
lmbench-3.0-a9.tgz から作成すると正しい結果が得られていることが判ります。
182: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lmbench
183: 0 /bin/cp
184: 0 /bin/date
185: 0 /bin/hostname
186: 0 /bin/mkdir
187: 0 /bin/mount
188: 0 /bin/netstat
189: 0 /bin/rm
190: 0 /bin/sleep
191: 0 /bin/sync
192: 0 /bin/tar
193: 0 /bin/uname
194: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_file_rd
195: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_mem
196: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_mmap_rd
197: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_pipe
198: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_tcp
199: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/bw_unix
200: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_connect
201: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_ctx
202: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_fs
203: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_http
204: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_mmap
205: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_pagefault
206: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_pipe
207: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_proc
208: 0 /bin/sh
209: 0 /tmp/hello
*** ↑ hello プログラムのドメインが作られている ***
210: 0 /tmp/hello
211: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_rpc
212: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_select
213: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_sig
214: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_syscall
215: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_tcp
216: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_udp
217: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lat_unix
218: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lmdd
219: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/lmhttp
220: 0 /root/lmbench-3.0-a9/bin/i686-pc-linux-gnu/msleep
221: 0 /sbin/ifconfig
222: 0 /usr/bin/awk
223: 0 /usr/bin/expr
224: 0 /usr/bin/touch
225: 0 /usr/bin/uptime
ということで、 lmbench/3.0-a9-1 を使う場合、事前に hello プログラムを /var/tmp/lmbench/hello にコピーするか、あるいは、 lmbench-3.0-a9.tgz からコンパイルしたものを使用するようにしてください。（これ以外にも不具合があるかもしれないので、修正が完了するまでは lmbench-3.0-a9.tgz からコンパイルする方がおススメです。）
CaitSith は Linux 2.6.27 以降のカーネル向けのアクセス制限モジュールです。元々は TOMOYO Linux の次期バージョンとして作成していたものが、あまりにも考え方や使い方の変更が大きくなりすぎてしまったため、「もはや TOMOYO とは呼べない」ということで新しい名前を付けました。
今日、初版をリリースしました。
http://sourceforge.jp/projects/tomoyo/lists/archive/users/2012-April/000968.html
Adobe Flash Plugin は rpm などの形式でインストールできますが、単にインストールしただけではブラウザから認識してくれないようです。しかも、最新版をインストールした後も Firefox が「安全のために最新版ではない Flash を無効化したよ（ For your safety, Firefox has disabled your outdated version of Flash. ）」なんて表示してくるものですから、「認識しているけど使っていない」のだと誤解するでしょう。
Firefox から認識できるようにするには、最新版をインストールした後に、以下のようにシンボリックリンクを張る必要があります。
| # ln -s /usr/lib/flash-plugin/libflashplayer.so /usr/lib/mozilla/plugins-wrapped/ |
ちょうどＤＮＳを使った隠れ通信ネタが出たので、熊猫からも１つ。
RHEL6.2 カーネルには、 Linux 3.0 で導入された sendmmsg() システムコールがバックポートされています。これを使うと、１回のシステムコールで複数の宛先に送信できるので、１個目のパケットだけでなく２個目以降のパケットについても宛先チェックをしないと、不審なホストとの隠れ通信に利用されてしまいます。
Linux 3.0.0 のリリース直後に sendmmsg() システムコールが追加されていることに気付き、ソースコードをチェックしてみたところ、ＬＳＭによるチェックは１個目のパケットの送信時だけしか行われていませんでした。そのため、「はぅ〜、１個目の宛先しかチェックできないのでは、 AKARI による送信先アドレスチェックが不完全なものになってしまうよ〜」とガッカリしました。当時、 TOMOYO 2.x にネットワークに対する送受信アドレスチェック機能を追加することも目指していたため、せっかくのパフォーマンス向上分を減少させてしまう仕様変更をどうやって提案しようかと悩みました。でも、幸いなことに、 SMACK が既に宛先アドレスから算出されるラベルに基づくアクセス制御を搭載していたため、 TOMOYO のための仕様変更パッチとしてではなく SMACK のためのリグレッション修正パッチとして提案することができました。
そうして Linux 3.0.2 で熊猫が提案したリグレッション修正パッチが取り込まれたのですが、そのパッチには別のバグがありました。そのバグを修正するパッチは Linux 3.0.5 で取り込まれました。
そんな中、 RHEL 6.2 のカーネル 2.6.32-220.el6 がリリースされた訳ですが、熊猫のリグレッション修正パッチだけしか含まれていなかったので、「熊猫のリグレッション修正パッチのバグを修正するパッチを忘れてるよ」と報告したところ、 CVE-2011-4594 として登録されてしまいました。何か対応が大げさな気がしないでもない。（＾＾；
で、その修正パッチを含んだカーネル 2.6.32-220.7.1.el6 がリリースされたことを今日知りました。
ところで、熊猫が提案したリグレッション修正パッチ、 SELinux しか有効にする気が無い RedHat 系カーネルにとっては、実はバックポートする必要性はありませんでした。なぜなら、 SELinux では宛先アドレスに基づくアクセス制御をしていないからです。情報フロー制御は気にするのに、 sendmmsg() システムコールを使って不審なホストのＤＮＳサービスとの隠れ通信をすることは気にしないとはこれ如何に？
マウント制限のパーミッションチェックが不正確になる場合があるのを修正しました。また、カーネル 3.4 に対応するための修正を行いました。カーネル 3.4 での修正がバックポートされた場合、古いバージョンでは起動時にカーネルパニックが発生するのでご注意ください。
http://sourceforge.jp/projects/tomoyo/lists/archive/users/2012-March/000963.html
先日、パス名を計算するために使用している __d_path() という関数に対する仕様変更が発生しました。この仕様変更により、カーネル 3.2-rc4 までは正常に動いていた TOMOYO や AKARI が、カーネル 3.2-rc5 からはカーネルパニックにより起動できなくなってしまいました。
この仕様変更は、カーネル 2.6.36 までバックポートされる可能性があり、少なくともカーネル 3.0 と 3.1 へはバックポートされる見込みです。 ccs-patch-1.8.3-20111118.tar.gz および akari-1.0.23-20111118.tar.gz はこの仕様変更に未対応であるため、今後は使用しないでください。この仕様変更に対応したものを、 ccs-patch-1.8.3-20111213.tar.gz および akari-1.0.24-20111213.tar.gz としてアップロードしましたので、そちらをご利用ください。
この仕様変更は、 TOMOYO 2.5 をカーネル 2.6.33 〜 3.1 にバックポートして使われる方、および、 TOMOYO 2.4 をカーネル 2.6.33 〜 3.0 にバックポートして使われる方にも影響します。不審な電話がかかってきたら・・・じゃなくて、カーネルパニックで起動できなくなったら、この仕様変更が原因の可能性を疑ってください。
TOMOYO 1.8 をバイナリパッケージで利用されている方は、今後のアップデートは仕様変更に対応したパッチを用いて作成されるため、対処は不要です。