PGACE/SE-PostgreSQLへの反応

昨日投げたPGACE/SE-PostgreSQLに対する反応

http://archives.postgresql.org/pgsql-hackers/2007-04/msg00691.php

Josh Berkus より:
Column level? We don't currently support that, except through VIEWs.
How is it implemented?
列レベルのアクセス制御は、リライト済みのクエリ木をスキャンして、クライアントがパーミッションを持っていないカラムへのアクセスを検出したら、トランザクションをアボートさせる。
Tom Laneより その1:
It wasn't clear to me how much of this is actually working today and how much is a paper design --- one thing in particular that stood out as probable handwaving was the bit about being able to assign to a system column in INSERT or UPDATE. I'm fairly sure that that would take some *significant* redesign of querytree and plan targetlist representation :-( ... I looked at it once for OIDs and decided it wasn't worth the trouble.
writable system columnについて。PostgreSQLではシステム列を対象にUPDATE/INSERTできない。しかし、SE-PostgreSQLではシステム列に対するUPDATE/INSERTが可能で、彼が昔やってみた方法では結構な修正が必要だったとの事。
(それにしても、机上デザインか動いてるのか不明確って…。orz)
私の方法はいたってシンプル。writable system columnである'security_context'がUPDATE/INSERTの対象として指定された時に、TargetEntryのresjunkをtrueにセットする。こうすると、値を計算するが後で捨てられるようになる。(ソートやGROUP BYで使われる機能)
で、これをExecInsert()やExecUpdate()呼び出し直前に取り出してHeapTupleにセットする。修正規模はたぶん100行にもならない。
Tom Laneより その2:
For people who are already using SELinux or Trusted Solaris, making the database dependent on that infrastructure might be seen as a plus, but I'm not sure the rest of the world would be pleased.
SELinux/T-Sol以外の人に何か役に立つの?と
どうも細粒度アクセス制御(行/列レベル)にフォーカスしているみたいなので、「最大の目的はOSセキュリティとの統合」というのを明言して、それ以外の環境では regression が無いことが要求される、というのを言ってみる。
とは言え、LSMがWindowsユーザに何か有益かと質問されても困るわん。
There are also some interesting questions about SQL spec compliance and whether a database that silently hides some rows from you will give semantically consistent results.
SQLのモデルを破壊しないことを説明しなければいかん。
ひとまず、WHERE句/JOIN ON句で追加の条件を付与するのと同じで、クライアントの元には常にフィルターされた結果セットが返ってくることを説明。

但し、例外は2つある。
一つは外部キー処理で、これは内部的にUPDATEやDELETEを実行して ON ... CASCADE の処理を行う。もし、CASCADE対象のタプルが5つあり、そのうち2つのタプルにパーミッションが無ければ更新不整合が起こりえる。SE-PostgreSQLはそれを避けるために、外部キーの処理中は、常に全てのCSCADE対象タプルにパーミッションを持っていることを要求する。
(持ってなかったら、即トランザクションアボート)

もう一つはTRUNCATE構文で、これは内部的に無条件のDELETE構文に変換される。テーブルの内容をクリアする命令だが、権限のないタプルまで消して良いわけは無い。

この辺の例外事項もきちっと書いたことで、ちゃんとソースを読んで分析してるなという印象を与えられればOK。PostgreSQLのコミュニティでは実績の無い新人なので「KaiGaiなら変なことは言わんだろう」という信頼感を醸成することが先ずは大切だ。

私もSELinuxのコミュニティに「AVCのスケーラビリティ改善をRCUでやる」と宣言した時には「やれるもんならやってみろ」とか言われたくらいだしね。