スレッドは(↓) FreeBSD-svn-commit ML(2014.1.29)
http://lists.freebsd.org/pipermail/svn-src-head/2014-January/055578.html
(XIJ-Jamie-patch)
Gleb Smirnoff:
これは自ら簡単に unjail 化するもんとちゃうんか？
Jamie:
その通り．そやから jail(8)で散々警告入れといたん や．そやけど，これ結構ニーズがあるんや
Alexander:
unjail 化するのは，そのフラグが設定された時だ けで，そうせんかったら jail のままなんで...．とりあえ ずデフォルトの devfs.rules で io を入 れとかんかったら良いかと...
＊そして遂にコアリーダの逆鱗に触れる＊
Robert Watson:
それば間違いだ．Jail のセキュリティを破っ てユーザがデバイスを操作できてはならないし，ユーザに直 接 I/O アクセスできることがわかってもいけない． はっきり言って．これは元に戻さないとだめだ．どうしても， このままにしたいのなら，生半可な注意じゃなくて本当に Jail を捨てる気があるのかというぐらいの明確な警告を明 示すべきだ．`obviate'(3)などという言葉は使うな．明確 に，「jail 内で root になれば jail を抜け出られる」と言 え．
Jamie:
はい．もう少しましなのにしてから出直しますです． 将来の課題として議論できればと思います．
Alexander:
了解しました．フラグは追加しないで devfs もそのまま にしときます．ある特別な jail に限ってのみ kmem へのア クセスが許されるという意味の内容でもっともっと頭をひねっ て書けるようにしますです．
allow.kmem
Jailed processes may access /dev/kmem and similar devices
(e.g. io, dri) if they have sufficient permission (via
the usual file permissions). Note that the device files
must exist within the jail for this parameter to be of
any use; the default devfs ruleset for jails does not
include any such devices. Giving a jail access to kernel
memory obviates much of the security that jails offer,
but can still be useful for other purposes. For example,
this would allow the Xorg server to run inside a jail.