素人翻訳

このサイトを読んだ時のメモ。

----------------

★「well known name」は、サービスを提供する場合に限って取得する。

★「D-Bus Mediation」が実施されるのは、サービス名の取得とメッセージの送信に対してである。

★メッセージの送信は「対称的な mediation」を伴う。すなわち、メッセージの送信者がメッセージを送信できるか否かを確認し、メッセージの受信者が同メッセージを受信できるか否かを確認する。したがって、１つの送信(send)で２つの監査メッセージが発生する。

★d-bus 自体のオーべーヘッドが大きいので、mediation のオーバーヘッドは問題にならない。

★network manager の振る舞いのために、一部のメッセージ(すでに死んでいるタスクからのメソッド・コール)の処理だけ complain モードで処理している。(２０１１年９月)

★ログ・メッセージのうちフィールド「pid=」が無いものは、dbus 自身から来たものである。

★ログ・メッセージのうちフィールド「tpid=」が無いものは、dbus 自身へ向かうものである。

★全ての dbus メッセージの送受信を許可し、且つ全てのサービス名の取得を許可したい場合、プロファイルには「dbus,」という規則だけを記述する。

★システム・バス上にて com.foo というサービス名の取得を許可するには「dbus system com.foo acquire,」という規則を記述する。

★２０１１年９月時点で使えるポリシーの書式は、

['audit'] ['deny'] dbus ['system'|'session'] [['address=']<address>] ['path='<path>] ['interface='<interface>] ['method='<method>] [<perms>] ','
<perms> := <perm> | '(' (<perm> ','|[\w]) <perm> ')'
<perm> := r, w, rw, send, receive, acquire, bind, read, write

である。

★permission のうち「r」「read」「receive」が同じ意味であり、「w」「write」「send」も互いに同じ意味であり、「bind」「acquire」も同じ意味である。

★記述された規則の中に省かれている要素(address、permsなど)があれば、その規則は、該当する要素の候補全てにマッチする。例えば「dbus com.foo,」は、com.foo へのメッセージの送信、com.foo からのメッセージの受信、及びサービス名「com.foo」の取得をセッション・バスとシステム・バスの両方で許可するという意味である。

★「dbus system com.foo w,」及び「dbus system com.foo send,」は、システム・バスにある com.foo へのメッセージの送信を許可するという意味である。

★複数の permission を指定する場合は括弧()を使う。例えば「dbus system com.foo (send, receive),」のように。括弧の中のコンマは無くてもよい。半角の空白だけでも機能する。「rw」だけは括弧の中でも外でも使用できる。

★同じ意味の permission を記載しても問題ない。例えば「dbus system com.foo (rw, send receive),」は有効な規則である。コンマのある箇所と無い箇所が混じっていてもよい。

★次の３つの規則も有効である。「deny dbus system com.foo path="/foo /bar" interface=com.bar method=fred rw, 」、「dbus address=com.foo path=/foo/bar (send receive),」、「dbus com.foo acquire,」

★「acquire」と「bind」は「address=」の式に対してのみ意味を持つ。それゆえ、それを示すための規則に path や method の情報を入れるのは変である。

★address、path、interface、method は apparmor の正規表現に対応しているので、特別な文字はエスケープする必要がある。

★２０１１年９月時点では「profile=」フラグはまだ実装されてない。そのため、通信のターゲット・プロファイルを指定することはできない。「dbus profile=/foo/bar,」と指定することで「/foo/bar」で制約されているタスクの通信だけを許可する、といった使い方を想定している。

dbus-bus.c の関数 dbus_bus_request_name() のコメントに名前の所有者の待ち行列の使い方が載っている。

org.freedesktop.TextEditor というアプリケーションがあり、このアプリケーションのインスタンスを複数同時に実行できるとする。その場合、そうしたインスタンス全てを名前の待ち行列の中に入れることができる。

最初に起動するインスタンス(待ち行列の先頭のもの)が org.freedesktop.TextEditor 宛てのメッセージを受信する。このインスタンスが終了すると、他のインスタンスが名前の筆頭所有者(primary owner)となりメッセージを受信するようになる。

この待ち行列が存在するおかげで、目的の名前の現在の所有者が消えるのを監視しつづけて再びその名前を要求するという動作が不要になる。

★RequestName のフラグについて

フラグは RequestName を呼び出すことで更新することができる。(すでにその名前の所有者であっても構わない。)

#DBUS_NAME_FLAG_REPLACE_EXISTING は、他の２つのフラグ(#DBUS_NAME_FLAG_ALLOW_REPLACEMENT と #DBUS_NAME_FLAG_DO_NOT_QUEUE)と異なり、個々の RequestName コールの属性である。つまり、メッセージ・バスは接続と名前の番いに対してずっと #DBUS_NAME_FLAG_REPLACE_EXISTING フラグを紐付けておくわけではない。