投稿

2016の投稿を表示しています

XKB で遊んでみよう (2)

xkb_keymap xkb_keymap エントリーは、xkb で使われる設定一式です。中身は
xkb_keycodesxkb_typesxkb_compatxkb_symbols の各エントリーからなります。おまけとして
xkb_geometry というエントリーも存在しますが、単に各種設定ツールでキーボードの絵を表示するのに必要な情報が入ってるだけなので、キーマップをいじるという観点ではガン無視でオッケーです。
xkb_keycodes デバイスから受け取ったスキャンコードに抽象的な名前、シンボル名を与えるための設定です。他のところの設定において、スキャンコードではなくここで設定されたシンボル名を使うことで、「Ctrl と Caps を入れ替える場合、US キーボードではスキャンコード 11 を Caps に、JP106キーボードの場合はスキャンコード 22 を Capsに」といった、キーボードとオプション設定の組み合わせ全てでスキャンコードを列挙する必要がなくなります。
ただし、抽象化の目的によって大きく分けて2種類のシンボル名が用意されています。一つは物理的な位置に基づくものです。最下段のキーは左から順に <AA00>, <AA01>, ... (ただし、最下段は特殊キーしかないのが普通なので、<AA00> 以外が使われることは稀)、下から2段目は <AB00> (左Shiftキーの位置), <AB01>, ... となっていきます。
もう一つは機能に基づくもので、<HKTG> (Hiragana-Katakana ToGgle) や <TLDE> (tilde) みたいなものがあります。ただし、あくまでもスキャンコードにシンボル名を与えるだけなので、<TLDE> が実際に ~ である必要はありません。というか、わざとややこしい例を出したのですが、<TLDE> は手前から5段目の右端のキー(US キーボードなら ~ キーがある位置)という、位置にあるキーのためのくシンボル名です。ややこしい。そういう意味であれば、単純に <AE00> にしとけと思うんですけどね。

日本語キーボードは、1 の隣は「半角/全角キー」なので、実際の設定ファイルか…

XKB で遊んでみよう (1)

元ネタは私の G+ポスト です。

Emacs を使ってるとどうしても小指が痛い。解決方法として

Emacsを使わない指の付け根でCtrlキーを押すフットペダルを使うなどが挙げられますが、 Emacs以外は考えられない体にされてしまっている。試してみてはいるけれど、ちょっとまだ慣れないあまり一般的でないハードウェアには依存したくないなどの理由により、X11 上でキーマップをゴニョゴニョしてなんとかしのげないかと考えるに至りました。
で、X11 上でキーマップをゴニョゴニョするといえば大昔は xmodmap 一択だったのですが、近年では XKB を使うのが一般的ではないかと思います。Fedora でモニョモニョしてた頃、とりあえずあら探しした記憶があるのですが、さすがに10年も触らないと忘れてしまいます。あと、個人的に X11 と djb の書いたコードは読まないことにしているので、こんなん書いている割に理解は浅いです。
XKB 使ってユーザーがキーマップをいじる場合、基本的に使うのは xkbcomp コマンドです。setxkbmap は xkbcomp の簡易ラッパーコマンドという認識でいいと思います。
setxkbmap, xkbcomp などで色々と検索すると何やら出てきますが、とりあえず「無変換」キーを Control キーとして (US キーボードで) 使うには
xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   {
                include "pc+us+inet(evdev)"
key <MUHE>{ [Control_L] };
                modifier_map Control { <MUHE>};
        };
        xkb_geometry  { include "pc(…

glibc getaddrinfo() 問題 (CVE-2015-7547) について

さて、いつも同じですが、今回もあくまでも個人としての投稿です。会社としては CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow 読んでということで。

脆弱性の内容、各ディストリビューションからのアップデートは各テック系サイトのニュースをご参照ください。

さて、大人の事情によりすぐに直せないよーという場合の緩和策(あくまでも緩和策です)として [PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflow では以下のものが挙げられてます:
UDP513 バイト以上の UDP DNS パケットを firewall で落とす(略) `options edns0` を /etc/resolv.conf で使わない。EDNS0 は 512 バイトより大きいレスポンスを許可するので、正当な DNS レスポンスでも overflow を発生させることが出来てしまいます(略)元のメールの想定読者がシステム管理者ではないので、クライアントコードでの mitigation は省略しました。

TCPDNS リプライを 1024 バイトまでに制限するこれはちょっと理由が分からなかった。なんでこれでいけるん?fragment が発生しない最小値 (MTU の最小値) は IPv4 なら 576 バイト、IPv6 なら 1280 バイト。DNS/TCP パケットを再構成した上で処理する firewall なら、2048 バイトじゃね?

read() のバッファサイズと発行回数の都合で、1 packet が 1024 バイトまでならバッファがあふれる前に処理できる可能性が高い? でも、「パケット」については言及されてない。

ちゃんと読んでから後で訂正するかもですが、単に A と AAAA の合計で 2048 バイト超えないようにしろってことだと思う。
有効でない緩和策
ちなみに、意味のない緩和策として

`options single-request` は内部でのバッファー管理方法に変わりはないので意味なし。`options single-request-reopen` も 1. と同様。IPv6 を無効にしても、(AF_UNSPEC が使われていると)AAA…