use bytes;perl 5.6.0 未満でも動いてほしいのであればこうなるかな。
$utf8off_str = substr $utf8on_str, 0;
BEGIN { eval { require bytes; bytes->import; }; }
$utf8off_str = substr $utf8on_str, 0;
use bytes;perl 5.6.0 未満でも動いてほしいのであればこうなるかな。
$utf8off_str = substr $utf8on_str, 0;
BEGIN { eval { require bytes; bytes->import; }; }
$utf8off_str = substr $utf8on_str, 0;
2.4.0 以降、 Linux はバインドマウントをサポートしている。バインドマウントとは、ディレクトリの symlink のようなもので、これによりあるディレクトリの内容を異なるパス間で共有することができる。例えば、 "mount --bind /foo /bar" は、 /foo の内容を /foo だけでなく /bar にも"バインド"する。別の言い方をすれば、 /foo 及び /bar が同じ内容になる。そして、一方のディレクトリ内で変更を行うと、他方にも変更が及ぶ。これは、 chroot や ftp/web サーバのようなもの対しては有用であるが、今までは、 /foo が書き込み可能であれば、 /bar もどうしても書き込み可能になってしまっていた。これは非常に身近な改善であろう。実現していることは単純で、すぐにでも応用されていきそうだが、カーネルのコード的にはやや複雑な変更のようだ。 VFS には、このように身近で明らかな改良の余地がまだまだ残されているので楽しみに待っている。
2.6.26では、読み取り専用で bind mount を行えるようになった。先ほどの例で行ったバインドマウントを読み取り専用で行うと、 /foo の内容は /bar にも現れるが、アプリケーションが /bar の中でファイルを修正しようとしてもできない。(もちろん、 /foo は書き込み可能なままである。)この機能は、色々と応用できる。 chroot では、ファイルシステムの一部を書き込み可能にすることができる。ユーザが、あるコンテナの中ではルートを持ってよいが、いくつかのファイルシステムへ書き込めてはいけない、というように、コンテナに便利である。新しいファイルシステム全体をマウントしておきたくはなかったり、 atime を選択的に更新したいときに、ファイルシステムの一部を読み取り専用にしておくことで、セキュリティの向上が可能となる(自分の FTP サーバを信頼していない場合など)。
(現在の実装は、直接読み込み専用でバインドマウントすることはできない。バインドマウントをまず行って、 - mount --bind /foo /bar - それから ro としてリマウントする - mount -o remount,ro /bar - 必要がある)
Linux 2.6.20 で導入された仮想化ソリューション KVM が x86 以外のアーキテクチャ、 IA64 (Itanium)、 S390 及び PPC をサポートできるように再構築された。KVM は Xen とは違い Intel VT とか AMD-V とかのハードウェア支援機構を全面的に利用した仮想化方式であるが、移植できたとなると応用範囲が広がりそうである。
1 年前 Linux 2.6.22 で Linux は新しいワイヤレススタックを導入した。 2.6.26 では open80211s プロジェクトによりこのスタックにメッシュネットワーキングが追加された。
PAT (ページ属性テーブル) とは、 x86 プロセッサにある機能で、ページごとの粒度でメモリの属性を設定するものである。 PAT は、物理アドレス範囲に対してメモリの種類を設定できる MTRR 設定と相補的なものである。しかしながら、 PAT はページレベルで属性を設定できる点、属性の設定可能な数にハードウェア上の制限が無い点において、 MTRR よりも柔軟性がある。 Linux にこれをサポートさせるための作業は長きに渡っていた(なんと2006年以来である)が、ついにマージされた。完全に俺の知らない領域だ。。。 Documentation/pat.txt に説明がある。
ファイルシステムのケイパビリティサポートにより、 (set)uid-0 ベースの特権を排除し、代わりにケイパビリティを用いることができるようになった。つまり、この機能がなくても、ファイルシステムのケイパビリティサポートがあれば、ケイパビリティだけでシステムを管理することが(概念的には)可能であり、 (set)uid-0 経由で特権を取得する必要が出てくることは無い。もちろん、概念的に可能であるというのは、現在可能であるとは言ってしまえないということである。現在、特権を行使するのにケイパビリティを活用するように作られたユーザアプリケーションは殆ど無く、まともなシステムを走らせるには、確実に十分とはいえない。さらに、アプリケーションの多くが、そういうふうにアップグレードされないであろうという状況にある。カーネルは、 setuid-0 ベースの特権の需要を満たすべくあり続けるであろう。ピュアケイパビリティのアプリケーションが発展し、 setuid-0 バイナリを置き換えるには、そういったアプリケーションが特権を内包できる機構があることが望ましい。この機構は、プロセス毎バウンディング及び継承可能セット (per-process bounding and inheritable sets) 、さらにプロセスの子供ツリーからの uid-0 スーパーユーザ権限の制限、からなっている。 2.6.26 で導入されたこの機構は、 (set)uid-0 に関連付けられた特権を制限するために活用することができる。制限を開始するには、 CAP_SETPCAP が必要であり、'現在'のプロセスにしかすぐには影響しない。(fork()/exec()を通して継承される。)この securebits の再実装は、システムワイドで、扱いづらく、枯れ果てており、現代のカーネルソースの化石となっている、過去の securebits サポートとは大きく異なっている。まあ確かに setuid には問題がありまくりなんだが、ここまで糾弾されると逆に擁護したくなるな。本文がわかりづらいので、わかりやすい日本語記事を紹介。何にでも制限かけるという方向にはあまり行ってほしくないけどね。