スキーマでのGRANT USAGEは正確に何をしますか?


121

私は初めてPostgresデータベースを作成しようとしているので、これはおそらく愚かな質問です。PHPロールからデータベースにアクセスする必要がある基本的な読み取り専用権限をdbロールに割り当てましたが、好奇心があります。実行した場合

GRANT some_or_all_privileges ON ALL TABLES IN SCHEMA schema TO role;

また実行する必要がありますか

GRANT USAGE ON SCHEMA schema TO role;

ドキュメントから:

使用法:スキーマの場合、指定されたスキーマに含まれるオブジェクトへのアクセスを許可します(オブジェクト自体の特権要件も満たされていることを前提とします)。基本的に、これにより、権限受領者はスキーマ内のオブジェクトを「検索」できます。

スキーマに含まれるデータを選択または操作できれば、スキーマ自体のオブジェクトにアクセスできると思います。私が間違っている?そうでない場合、何GRANT USAGE ON SCHEMAに使用されますか?また、「オブジェクト自体の特権要件も満たされていると想定して」というドキュメントの正確な意味は何ですか?

回答:


126

GRANT異なるオブジェクトのsは別々です。GRANTデータベースでの操作はGRANT、その中のスキーマに対する権限を持ちません。同様に、GRANTに、スキーマを使用しても、その中のテーブルに対する権限は付与されません。

SELECTテーブルからの権限はあるが、それを含むスキーマでそれを表示する権限がない場合は、テーブルにアクセスできません。

権利テストは次の順序で行われます。

Do you have `USAGE` on the schema? 
    No:  Reject access. 
    Yes: Do you also have the appropriate rights on the table? 
        No:  Reject access. 
        Yes: Check column privileges.

publicスキーマにはGRANT、ロールに対するすべての権限のデフォルトがあり、すべてのpublicユーザー/グループがメンバーであるという事実から、混乱が生じる可能性があります。したがって、誰もがすでにそのスキーマを使用しています。

表現:

(オブジェクト自体の特権要件も満たされていると想定)

USAGEスキーマ内でオブジェクトを使用するにはスキーマが必要であると述べていますが、USAGEそれだけではスキーマ内のオブジェクトを使用するには十分ではなく、オブジェクト自体に対する権限も必要です。

これは、ディレクトリツリーのようなものです。somedirファイルを含むディレクトリを作成する場合はsomefile、自分のユーザーだけがディレクトリまたはファイルにアクセスできるように設定します(rwx------dirのモードrw-------、ファイルのモード)。他の誰もディレクトリをリストして、ファイルが存在することを確認できません。

ファイル(mode rw-r--r--)に対する全ユーザーの読み取り権限を付与しても、ディレクトリのアクセス許可を変更しない場合、違いはありません。ディレクトリを一覧表示する権限がないため、ファイルを読んで誰も見ることができませんでした。

代わりにrwx-r-xr-xディレクトリを設定し、ユーザーがディレクトリを一覧表示してトラバースできるが、ファイルのアクセス許可を変更できないように設定すると、ユーザーはファイルを一覧表示できますが、ファイルへのアクセス権がないため、ファイルを読み取ることができません。

実際にファイルを表示できるようにするには、両方の権限を設定する必要があります。

ページで同じこと。テーブルUSAGEなどSELECTからオブジェクトに対してアクションを実行するには、スキーマ権限とオブジェクト権限の両方が必要です。

(たとえ、PostgreSQLにはまだ行レベルのセキュリティがないため、アナロジーは少し低下します。そのため、ユーザーは直接SELECTからINGを実行することで、スキーマにテーブルが存在することを「確認」できますpg_class。ただし、同じではないのは単なる「リスト」部分です。)


2
これで、ディレクトリの例で非常に明確になりました。たとえば、スーパーユーザーでテーブルまたは行を挿入する場合、たとえばを使用してpostGISを追加する場合、これが問題であることを言わなければなりませんCREATE EXTENSION。Linuxで作成されたファイルの問題は多かれ少なかれ同じですsusudo -epqslにある種のforステートメントがあるとよいでしょう。
Marco Sulla 2013年

とにかくGRANT、すべてのデータベースに影響を与えるため、テーブルに固有でないステートメントは私が望むものではないことに気づきました...:s
Marco Sulla

1
@LucasMalor Er ...いいえ、そうではありません。GRANTスキーマでそのスキーマに影響します。GRANT ... ON ALL TABLES IN SCHEMA ...特定のデータベースのスキーマ内のすべてのテーブルに影響します。GRANTすべてのデータベースに影響を与えるはありません(GRANTユーザーにロールメンバーシップを与えることを除いて、問題ありません)。
クレイグリンガー2013年

すみません、「postgres」スーパーユーザーとしてログインしたときにステートメントを実行しましたが、「postgres」データベースに影響を与えました。dbの「外部」を操作psqlせずに実行する-d dbと、常にdbに接続され、デフォルトでは同じ名前のロールを持つdbに接続されていると思いました。db = role = user = group ...それは少し紛らわしいです:D
Marco Sulla

@LucasMalorこのように考えてください。デフォルトでは、接続に使用したログインロール(「ユーザー」)と同じ名前のDBに接続します。「ユーザー」は、WITH LOGIN。基本的に、すべてが基であることができ、およびグループがログインできるように設定することができます。
クレイグリンガー

72

本番システムでは、次の構成を使用できます。

--ACCESS DB
REVOKE CONNECT ON DATABASE nova FROM PUBLIC;
GRANT  CONNECT ON DATABASE nova  TO user;

--ACCESS SCHEMA
REVOKE ALL     ON SCHEMA public FROM PUBLIC;
GRANT  USAGE   ON SCHEMA public  TO user;

--ACCESS TABLES
REVOKE ALL ON ALL TABLES IN SCHEMA public FROM PUBLIC ;
GRANT SELECT                         ON ALL TABLES IN SCHEMA public TO read_only ;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO read_write ;
GRANT ALL                            ON ALL TABLES IN SCHEMA public TO admin ;

スキーマadminに対しても許可CREATEされるべきではありませんか?
ダン、

2
アクセスは、階層モデル(BD-> SCHEMA-> TABLES)に従って割り当てられます。を使用するGRANT USAGE ON SCHEMAと、管理者ユーザーはテーブルを作成できませんが、テーブルを作成できますALL GRANT ALL ON SCHEMA...
bilelovitch

@bilelovitch:つまりgrant all on schema public to admin?PS:私も追加しました grant usage, select on all sequences in schema public to read_only/read_write; grant execute on all functions in schema public to read_only/read_write;
Marco Sulla

2

まあ、これはLinux用の単純なdbの私の最終的な解決策です。

# Read this before!
#
# * roles in postgres are users, and can be used also as group of users
# * $ROLE_LOCAL will be the user that access the db for maintenance and
#   administration. $ROLE_REMOTE will be the user that access the db from the webapp
# * you have to change '$ROLE_LOCAL', '$ROLE_REMOTE' and '$DB'
#   strings with your desired names
# * it's preferable that $ROLE_LOCAL == $DB

#-------------------------------------------------------------------------------

//----------- SKIP THIS PART UNTIL POSTGRES JDBC ADDS SCRAM - START ----------//

cd /etc/postgresql/$VERSION/main
sudo cp pg_hba.conf pg_hba.conf_bak
sudo -e pg_hba.conf

# change all `md5` with `scram-sha-256`
# save and exit

//------------ SKIP THIS PART UNTIL POSTGRES JDBC ADDS SCRAM - END -----------//

sudo -u postgres psql

# in psql:
create role $ROLE_LOCAL login createdb;
\password $ROLE_LOCAL
create role $ROLE_REMOTE login;
\password $ROLE_REMOTE

create database $DB owner $ROLE_LOCAL encoding "utf8";
\connect $DB $ROLE_LOCAL

# Create all tables and objects, and after that:

\connect $DB postgres

revoke connect on database $DB from public;
revoke all on schema public from public;
revoke all on all tables in schema public from public;

grant connect on database $DB to $ROLE_LOCAL;
grant all on schema public to $ROLE_LOCAL;
grant all on all tables in schema public to $ROLE_LOCAL;
grant all on all sequences in schema public to $ROLE_LOCAL;
grant all on all functions in schema public to $ROLE_LOCAL;

grant connect on database $DB to $ROLE_REMOTE;
grant usage on schema public to $ROLE_REMOTE;
grant select, insert, update, delete on all tables in schema public to $ROLE_REMOTE;
grant usage, select on all sequences in schema public to $ROLE_REMOTE;
grant execute on all functions in schema public to $ROLE_REMOTE;

alter default privileges for role $ROLE_LOCAL in schema public
    grant all on tables to $ROLE_LOCAL;

alter default privileges for role $ROLE_LOCAL in schema public
    grant all on sequences to $ROLE_LOCAL;

alter default privileges for role $ROLE_LOCAL in schema public
    grant all on functions to $ROLE_LOCAL;

alter default privileges for role $ROLE_REMOTE in schema public
    grant select, insert, update, delete on tables to $ROLE_REMOTE;

alter default privileges for role $ROLE_REMOTE in schema public
    grant usage, select on sequences to $ROLE_REMOTE;

alter default privileges for role $ROLE_REMOTE in schema public
    grant execute on functions to $ROLE_REMOTE;

# CTRL+D

1
「#すべてのテーブルとオブジェクトを作成し、その後に」に使用する必要があるユーザーは?あなたの場合、テーブルと他のオブジェクトの所有者は誰ですか?
Christophe Furmaniak

@ChristopheFurmaniakそうですね、プロセスを修正しました。dbとそのオブジェクトの所有者は$ ROLE_LOCALであり、db構造を作成した後、postgresスーパーユーザーに戻る必要があります。
Marco Sulla

「ALTER DEFAULT PRIVILEGES ...」コマンドに問題があると思います。このコマンドは、別のユーザー(ロール)がオブジェクトを作成するときに、1人のユーザー(ロール)への権限付与をトリガーするために使用されます。詳細については、このドキュメントの 11ページのセクション7.1を参照してください。現在、ROLE_REMOTEはROLE_LOCALが作成するオブジェクトにアクセスできません。ROLE_LOCALコマンドは、ロールがそれらのオブジェクトの所有者としてすでに持っている特権のみを与えます。ROLE_REMOTEコマンドについても同様です。
emispowder
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.