Access control#
カタログテーブル#
システムカタログと情報スキーマテーブルは、PGDによってレプリケーションから常に除外されます。
さらに、拡張機能が所有するテーブルはレプリケーションから除外されます。
PGDファンクションと演算子#
すべてのPGDファンクションはbdr
スキーマで公開されています。これらのファンクションへの呼び出しは、search_pathにbdr
を配置するのではなく、スキーマ修飾する必要があります。
すべてのPGD演算子はpg_catalog
スキーマを介して使用できるため、ユーザーはsearch_pathからpublic
スキーマを問題なく除外できます。
カタログオブジェクトに対する特権の付与#
管理者は、テーブル、ビュー、ファンクションなどのカタログオブジェクトに対する明示的な特権を付与してはなりません。 PGD predefined roles で説明されているロールのいずれかを付与して、これらのオブジェクトへのアクセスを管理します。
この要件は、結合のどちらの側のノードも全く同じバージョンのPGD、したがってPGDカタログを持たない場合でも、ノードグループに参加できる柔軟性の結果です。
より正確には、個々のカタログオブジェクトの特権が明示的に付与された場合、参加するノードから抽出された対応する
GRANTステートメントが参加しているノードに適用されない可能性があるため、
bdr.join_node_group() プロシージャーは失敗する可能性があります。
トリガー#
PostgreSQLでは、テーブルの所有者とTRIGGER特権を付与された人は誰でもトリガーを作成できます。非テーブル所有者によって付与されたトリガーは、 PGDでテーブル所有者として実行されます。これは、セキュリティ問題を発生させる可能性があります。 TRIGGER特権はめったに使用されず、PostgreSQLコアチームは、「個別のTRIGGER権限は時代遅れだと考えられるものです。」と述べています。
PGDは、テーブルにトリガーを作成できる人に関するより厳密なルールを使用することにより、この問題を緩和します。
スーパーユーザー トリガーを作成できます。
bdr_superuser トリガーを作成できます。
テーブルの所有者 PostgreSQLと同じルールに従ってトリガーを作成できます。トリガーによって使用されるファンクションのEXECUTE特権が必要です。
テーブルに対するTRIGGER特権を持つユーザー テーブルと同じ所有者が所有するファンクションを使用し、標準のPostgreSQLルールを満たす場合にのみトリガーを作成できます。具体的には、ファンクションのEXECUTE特権が必要です。 テーブルとファンクションの両方の所有者が同じで、所有者がユーザーにテーブルのTRIGGER特権とファンクションのEXECUTE特権の両方を付与することにした場合。そのユーザーがこのファンクションを使用してそのテーブルにトリガーを作成してもよいと想定されています。
テーブルに対するTRIGGER特権を持つユーザー
SECURITY DEFINER clause で定義されたファンクションを使用してトリガーを作成することもできます
EXECUTE権限がある場合。 SECURITY DEFINER句により、ファンクションは常に標準のPostgreSQLとPGDの両方でファンクションの所有者として実行されます。
このロジックは、 PostgreSQLでは、トリガーの所有者がそれを作成したユーザーではなく、そのトリガーが使用するファンクションの所有者であるという事実に基づいて構築されています。
同じルールが既存のテーブルに適用され、既存のテーブルに、テーブルの所有者が所有せず、SECURITY DEFINERファンクションを使用しないトリガーがある場合、レプリケーションセットに追加することはできません。
PGDレプリケーションは変更を適用する場合、システムレベルのデフォルトのsearch_pathのみを使用します。他のsearch_path設定を想定しているレプリカトリガー、ストリームトリガー、およびインデックス式ファンクションは、適用時に実行すると失敗します。これが発生しないようにするには、デフォルトのsearch_pathのみを使用してオブジェクト参照を明確に解決するか、影響を受けるファンクションにALTER FUNCTION ... SET search_path = ...
を使用してファンクションの検索パスを設定します。デフォルトのsearch_pathを使用する場合、schema.objectnameなどのオブジェクトへの完全修飾参照を常に使用します。