[pgsql-jp: 30812] Re: アクセス認証の改造

[谷口 彰]

谷口です。

> 私もテストしましたけど．バージョンは7.3.4です．

石井様のおっしゃる通りです 。
検証までしていただき、感謝いたします。
ペコリ。

私と同様に、大量アカウントを管理する必要のある方の参考になれば幸いです。
近い将来、オンラインデータは水道水のように利用されると思いますから。

以下、再検証の結果です。

以下の条件で再度テストしました。
RedHat Linux 9
PostgreSQL 7.3.2
BLKSZ = 8192

(1) GRANT SELECT ON test TO uXXXXX;

2444件目で以下のエラー
Tuple is too big: size 8140, max size 8136

(2) ALTER GROUP grouptest ADD USER uXXXXX;

9486件で検証中断
レスポンスが極端に低下したため（pg_shadow と pg_group の更新毎にキャッシュ
ファイルが書き換えられるためと思われる）
運用しているサーバでは BLKSZ=32768であり、検証としては十分なため

(1) のテストで不可であったため、グループも同様であろうと判断したようです。
pg_class.relacl の型は aclitem[] であるのに対し、pg_group.grolist の型は
integer[] です。
実際の格納サイズは、配列へのポインタや格納している型が影響しているようです。
単純に考えると、pg_group.grolist の件数は
length = ( 8192(BLKSZ) - 9("grouptest") - 4(grosysid) ) / 4(grolist)
        = 2044.75
となるのですが？
単純に BLKSZ から計算できないことははっきりしました（多分TOASTによる）。
このへんは今後のために研究したいところです。

結論として、以下の運用で行こうと思います。

１．データベース毎にアクセスレベルに対応したグループを定義
２．データベース内のテーブル毎に上記グループへ GRANT/REVOKE
３．ユーザを登録
４．利用状況に応じ、ユーザを、グループへ追加・グループから削除

ただし、これは (1) のテストが不可であるための対応です。
まあ、かえって管理が楽だと考える方もおられるかもしれません。
ユーザグループをサポートしていない DBMS もあるので、注意が必要です。

当面の運用は可能ですが、やはり、根本的な解決ではないので、こつこつと個人レベ
ルで改造しようと思います。

やっぱり英語を勉強して postgresql.org に参加すべきだった気がします。
しかし、オープンソースはすばらしいですね！

追伸

『PostgreSQLによるデータベース構築技法』（石井様！）を読ませていただきまし
た。スキーマを積極的に利用しようと思います。

----------------------------------------
DataSource    http://www.datasource.jp/
谷口　彰        akira ＠ datasource.jp