ヘッダーをスキップ

Oracle Rdb SQLリファレンス・マニュアル リリース7.2 E06178-01 |
| 目次 | 索引

戻る | 次へ |

列の権限は、特定の列ACLに対して指定された権限との組合せで表に対して定義された権限によって決まります。

SELECT権限は、UPDATEおよびREFERENCESを除く他のすべてのデータ操作の前提条件です。SELECT権限を付与しないと、事実上、権限リストで指定されている権限も含めて、SELECT、INSERTおよびDELETEの各権限を拒否します。SELECT権限をユーザー自身が拒否することはできません。

SELECT、INSERT、UPDATEおよびDELETEのデータ操作権限では、SQLは、特定の表へのアクセスを許可する前にデータベースと個々の表のACLをチェックします。たとえば、EMPLOYEES表のSELECT権限を付与された場合、EMPLOYEES表を含むデータベースのSELECT権限も所有している場合を除き、表の行の選択ができません。

表に対するUPDATE権限のあるユーザーは、表のすべての列に対して自動的にUPDATE権限を受領します。列を更新するには、列または表に対するUPDATE権限が必要です。ただし、UPDATE権限は、ユーザーによる更新が可能な特定の列のみを定義し、表エントリからUPDATE権限を削除することによって制限できます。

列のデータは、列に対するUPDATE権限およびデータベースに対するSELECT権限でのみ変更できます。

REFERENCES権限により、ANSI/ISOスタイルの権限のあるデータベースの制約を定義できます。ACLスタイルの権限のあるデータベースでは、制約を定義するにはCREATE権限が必要です。

作成するデータベースまたは表のDBCTRL権限をユーザー自身が拒否することはできません。この制限によって、機能すると予想したGRANT文が失敗する場合があります。

たとえば、ACLにPUBLICのエントリがないとします。DBCTRL権限を含まないACLの最上部にPUBLICのエントリを作成し、所有者を含むリストのすべての他のエントリのDBCTRLを事実上拒否しているため、次のGRANT文は失敗します。

    SQL> GRANT SELECT, INSERT ON EMPLOYEES TO PUBLIC;
    %RDB-E-NO_PRIV, privilege denied by database facility

### role-name

ロールの名前です。CREATE ROLE文で作成されたロール名または自動作成されるロール名などが該当します。（オペレーティング・システムのグループまたは権利の識別子としてロール名が存在する場合、GRANT文が発行されると、Oracle Rdbではロールが自動的に作成されます。自動的に作成されるロールは、常にIDENTIFIED EXTERNALLYの属性を持ちます。）

### TO identifier

### TO PUBLIC

新規または変更されたACLエントリの識別子を指定します。PUBLICの指定は、すべてのユーザー識別子のワイルドカード指定に相当します。

次の4種類の識別子を指定できます。

- ユーザー識別子

- 汎用識別子

- システム定義識別子

- ロール名

複数の識別子を指定するには、各識別子をプラス記号（+）で結合します。これらの識別子は複数識別子と呼ばれます。 この識別子では、個々の識別子によって定義されたグループすべてに共通するユーザーのみが識別されます。識別子すべてと一致しないユーザーは、そのエントリによって制御されません。

たとえば、複数識別子SECRETARIES + INTERACTIVEでは、対話型プロセスの汎用識別子SECRETARIESで定義されたグループのメンバーのみが指定されます。対話型プロセスではないSECRETARIESグループのメンバーは識別されません。

次の引数は3種類の識別子を簡潔に説明します。識別子の詳細は、使用中のオペレーティング・システムのドキュメントを参照してください。

### system-identifier

システムのインストール時に権限データベースが作成される際に、OpenVMSシステムによって自動的に定義される識別子を指定します。システム定義識別子は、実行するログインのタイプに応じて割り当てられます。有効なすべてのシステム定義識別子を次に示します。

> BATCH
> NETWORK
> INTERACTIVE
> LOCAL
> DIALUP
> REMOTE

### user-identifier

システム上の各ユーザーを識別します。

ユーザー識別子は、標準のOpenVMSのユーザー識別コード（UIC）、グループ名およびメンバー名（ユーザー名）で構成されます。グループ名はオプションです。ユーザー識別子には、数値形式または英数字形式を使用できます。次に、同じユーザーを識別する有効なすべてのユーザー識別子を示します。

> K_JONES
> [SYSTEM3, K_JONES]
> [341,311]

ユーザー識別子の一部としてアスタリスク（*）のワイルドカード文字を使用できます。たとえば、1つのグループ内のすべてのユーザーを指定する場合は、識別子として[system3, *]を入力できます。

Oracle Rdbでは、データベースの作成時に識別子[*,*]（PUBLICとも呼ばれる）を含むACLエントリが自動的に作成されます。このエントリによって、システム上のすべてのユーザーに付与する権限を指定します。

複数のユーザー識別子を複数識別子で使用することはできません。

## 使用方法

> - SHOW PROTECTION文およびSHOW PRIVILEGES文に変更が表示されても、再度データベースにアタッチするまではACLへの追加と変更が有効になりません。他のユーザーに対してACLへの追加と変更が有効になるのは、他のユーザーが再度データベースにアタッチした後です。

> - GRANT文で参照するすべてのデータベースにアタッチする必要があります。デフォルトの別名を使用する場合は、データベースACLで別名RDB$DBHANDLEを使用する必要があります。

> - GRANT文を使用すると、既存のACLエントリを変更するか、新規エントリを作成できます。
>   既存のACLエントリを変更するには、既存のエントリにある識別子と同じものをTO句で指定します。
>   新規ACLエントリを作成するには、エントリの一部になっていない識別子を指定します。

> - 新しい表とビューを作成すると、デフォルトでNONEのPUBLICアクセスが付与されています。

> - 新たに作成された表のPUBLICアクセスを無視するには、システム権限データベースにDEFAULTの名前で識別子を定義します。データベースについてこの識別子に付与するアクセス権限は、作成した新しい表およびビューのPUBLICに割り当てられます。
>   別名TEST1のデータベースにSELECT権限およびUPDATE権限を割り当てるとします。次に例を示します。

>       SQL> ATTACH 'ALIAS TEST1 FILENAME personnel';
>       SQL> SHOW PROTECTION ON DATABASE TEST1.
>       Protection on Alias TEST1
>           (IDENTIFIER=[dbs,smallwood],ACCESS=SELECT+INSERT+UPDATE+DELETE+SHOW+
>            CREATE+ALTER+DROP+DBCTRL+OPERATOR+DBADM+REFERENCES+SECURITY)
>           (IDENTIFIER=[*,*],ACCESS=NONE)
>       SQL> GRANT SELECT, UPDATE ON DATABASE ALIAS TEST1
>       cont> TO DEFAULT;

>   保護を変更するためトランザクションをコミットおよび切断する必要があります。

>       SQL> COMMIT;
>       SQL> DISCONNECT DEFAULT;

>   データベースの既存の表に対する保護は変更されません。ただし、定義する新しい表はDEFAULT識別子で指定された保護を受けます。この例では、所有者（SMALLWOOD）は、新しい表TABLE1に対するすべてのアクセス権限を受領し、その他のユーザーはDEFAULT識別子で指定されたSELECTアクセス権限およびUPDATEアクセス権限を受領します。

>       SQL> ATTACH 'ALIAS TEST1 FILENAME personnel';
>       SQL> SET TRANSACTION READ WRITE;
>       SQL> CREATE TABLE TEST1.TABLE1
>       cont>       (LAST_NAME_DOM CHAR(5),
>       cont>        YEAR_DOM SMALLINT);
>       SQL> SHOW PROTECTION ON TEST1.TABLE1;
>       Protection on Table TABLE1
>           (IDENTIFIER=[dbs,smallwood],ACCESS=SELECT+INSERT+UPDATE+DELETE+SHOW+
>             CREATE+ALTER+DROP+DBCTRL+DBADM+REFERENCES+SECURITY)
>           (IDENTIFIER=[*,*],ACCESS=SELECT+UPDATE)

>   DEFAULT識別子は通常、OpenVMSシステム上にあります。常にDEFAULTアカウントが存在し、削除できないためです。ただし、そのアカウントに関連付けられたDEFAULT識別子は削除できます。DEFAULT識別子がシステムから削除されると、Oracle Rdbによってエラー・メッセージが返されます。

>       SQL> GRANT INSERT ON DATABASE ALIAS TEST1 to DEFAULT;
>       %SYSTEM-F-NOSUCHID, unknown rights identifier

> - DBADM権限およびSECURITY権限は、Oracle Rdbの2つのロール指向権限です。これらの権限を所有するユーザーは、特定のシステムレベルの操作を実行できるように、一部のオブジェクトのACLを無視できます。Oracle Rdbのロール指向権限は、付与されたデータベースに限定されます。
>   2つのロール指向データベース権限は、相互に無視できません。（たとえば、DBADM権限はSECURITY権限を無視しません。）
>   このようなロール指向権限のいずれかを所有するユーザーは、暗黙的に他の特定のOracle Rdb権限を付与されていることがあります。暗黙的権限は、無視の結果として付与された権限です。ユーザーは実際に権限を保持しているかのように実行しますが、権限は明示的に付与されておらずオブジェクト用にACLに格納されています。
>   表6-10は、Oracle Rdb DBADMおよびSECURITYデータベース権限と、OpenVMSのSYSPRV、BYPASSおよびREADALLの各権限により、どのOracle Rdb権限を無視できるかを示しています。表の各エントリは、表の最上部の列に指定されたOracle Rdb権限またはOpenVMS権限を持つユーザーが、表の最初の列のOracle Rdb権限に関連付けられたアクセス権を暗黙的に受領するかどうかを示します。
>   たとえば、表の最初のエントリYは、Oracle Rdb DBADM権限がOracle Rdb ALTER権限を無視することを示し、2番目のエントリNはOracle Rdb SECURITY権限がOracle Rdb ALTER権限を無視しないことを示します。表のN/Aは、権限はそれ自体を無視できないことを示します。

>   表6-10 権限のオーバーライド機能
>   | データベース権限 | OpenVMS権限
>   --- | --- | ---
>   権限 | DBADM | SECURITY | SYSPRV | BYPASS | READALL
>   ALTER | Y | N | Y | Y | N
>   CREATE | Y | N | Y | Y | N
>   DBADM | N/A | N | Y | N | N
>   DBCTRL | Y | Y | Y | N | N
>   DELETE（データベース） | Y | Y | Y | Y | N
>   DELETE（表） | Y | N | Y | Y | N
>   DISTRIBTRAN | Y | N | Y | Y | N
>   DROP | Y | N | Y | Y | N
>   EXECUTE | Y | Y | N | N | N
>   INSERT（データベース） | Y | Y | Y | Y | N
>   INSERT（表） | Y | N | Y | Y | N
>   REFERENCES | Y | N | Y | Y | N
>   SECURITY | N | N/A | N | N | N
>   SELECT（データベース） | Y | Y | Y | Y | Y
>   SELECT（表） | Y | N | Y | Y | Y
>   SHOW | Y | N | Y | Y | Y
>   UPDATE（データベース） | Y | Y | Y | Y | N
>   UPDATE（表） | Y | N | Y | Y | N

> - DBADMデータベース権限のあるユーザーは、オブジェクトのACLに関係なく、データベースを含めた名前付きオブジェクトに対してデータ定義やデータ操作を実行できます。DBADM権限により、Oracle Rdbで実行されるほとんどの権限チェックは無視されるため、Oracle Rdbで最も強力な権限です。DBADMデータベース権限のあるユーザーは、暗黙的にすべてのオブジェクトのすべての権限を受領します。ただし、SECURITYデータベース権限は除きます。

> - SECURITYデータベース権限のあるユーザーは、暗黙的にOracle RdbのSELECT、INSERT、UPDATEおよびDELETEの各データベース権限およびOracle Rdb DBCTRLデータベース権限およびOracle Rdb DBCTRL表権限を受領します。

> - GRANT文は読取り/書込みトランザクションで実行する必要があります。アクティブなトランザクションがない場合にこの文を発行すると、Oracle Rdbでは、読取り/書込みトランザクションが暗黙的に開始されます。

> - RDB$SYSTEM記憶域が読取り専用に設定されている場合、GRANT文は実行できません。最初にRDB$SYSTEMを読取り/書込みに設定する必要があります。RDB$SYSTEM記憶域の詳細は、『Oracle Rdb7 Guide to Database Maintenance』を参照してください。

> - ユーザーがデータベースを作成する権利を拒否できます。

>   - RDBVMS$CREATE_DB権利識別子とともにRDBVMS$CREATE_DB論理名を使用して、ユーザーがデータベースを作成する権利を拒否できます。RDBVMS$CREATE_DB論理名の詳細は、『Oracle Rdb7 Guide to Database Design and Definition』を参照してください。

>     注意 RDBVMS$CREATE_DB論理名を使用する場合、他のインストール済サード・パーティ製品はOracle Rdbを使用してOracle Rdbデータベースを作成できません。したがって、それらの製品のユーザーがOracle Rdbデータベースを作成する必要がある場合は、この論理名の設定を解除する必要があります。

>   - CREATE MODULEを使用して作成したプロシージャまたはファンクションに対して、権限のGRANTを実行できません。かわりにモジュールに対してGRANTを使用してください。

>   - ユーザー識別子に権限を付与すると、セキュリティ・チェックを内部に設定している場合、SQLではそのユーザーがデータベース・ユーザーとして自動的に作成されます。
>     事実上、これはシステム・ユーザーに対してCREATE USER文を発行することと同様です。「例」の項の「例7」を参照してください。

>   - Oracle Rdbリリース7より前は、グローバル一時表およびローカル一時表でデータ操作に必要な権限は、実表で必要な権限と同じでした。たとえば、グローバル一時表に挿入を実行するには、ユーザーはデータベース・レベルでSELECT+INSERT権限が必要でした。
>     この要件は、実表への挿入操作により暗黙的にデータベースにデータが挿入されるため存在しました。データベース・レベルで付与される権限は、表に対する権限をフィルタ処理するために使用されていました。
>     ただし、実表とは異なり、一時表のデータは実際にはデータベースに格納されません。このため、一時表ではデータベースを更新しません。
>     Oracle Rdbリリース7以降、データ操作中にセキュリティ検証を実行する場合は、一時表に関連付けられた権限のみが考慮されます。たとえば、ユーザーがデータベースにアタッチでき（SELECT権限のみ必須）、グローバル一時表またはローカル一時表に対するINSERT権限が付与されている場合、ユーザー（または実行者の権限ストアド・ルーチン）は一時表を更新できます。この変更はRdbに対するSQL*Netの操作に反映され、一時表を処理するためのデータベース操作の権限（INSERT、UPDATE、DELETE）は不要になりました。
>     このセキュリティ・チェックの緩和は一時表にのみ適用されます。

>   Oracle Rdbデータベースの保護の詳細は、『Oracle Rdb7 Guide to Database Design and Definition』の権限の定義に関する章を参照してください。

## 例

> 例1: ACLの変更を有効にするためのデータベースの再宣言

> この例では、GRANT文およびREVOKE文が有効になるのは、再度データベースにアタッチした後であることを示しています。

>     SQL> -- Display the ACL for the EMPLOYEES table:
>     SQL> SHOW PROTECTION ON TABLE EMPLOYEES;
>     Protection on Table EMPLOYEES
>         (IDENTIFIER=[sql,warring],ACCESS=SELECT+INSERT+UPDATE+DELETE+SHOW+CREATE+
>           ALTER+DROP+DBCTRL+DBADM+REFERENCES)
>         (IDENTIFIER=[*,*],ACCESS=SELECT+INSERT+UPDATE+DELETE+ALTER+DROP)
>     SQL>
>     SQL> -- User warring, the owner of the database, denies
>     SQL> -- herself INSERT access to the EMPLOYEES table:
>     SQL> REVOKE INSERT ON TABLE EMPLOYEES FROM warring;
>     SQL> COMMIT;
>     SQL>
>     SQL> -- The SHOW PROTECTION statement displays the change
>     SQL> -- (INSERT is no longer part of the ACL entry
>     SQL> -- for warring):
>     SQL> SHOW PROTECTION ON TABLE EMPLOYEES;
>     Protection on Table EMPLOYEES
>         (IDENTIFIER=[sql,warring],ACCESS=SELECT+UPDATE+DELETE+SHOW+CREATE+ALTER+
>           DROP+DBCTRL+DBADM+REFERENCES)
>         (IDENTIFIER=[*,*],ACCESS=SELECT+INSERT+UPDATE+DELETE+ALTER+DROP)
>     SQL>
>     SQL> -- But the change is not yet effective.
>     SQL> -- User warring can still store rows in the EMPLOYEES table:
>     SQL> INSERT INTO EMPLOYEES (EMPLOYEE_ID) VALUES ('99999');
>     1 row inserted
>     SQL> SELECT EMPLOYEE_ID
>     cont>   FROM EMPLOYEES
>     cont>   WHERE EMPLOYEE_ID = '99999';
>      EMPLOYEE_ID
>      99999
>     1 row selected
>     SQL> ROLLBACK;
>     SQL>
>     SQL> -- To make the ACL change take effect, issue another ATTACH statement
>     SQL> -- to override the current declaration:
>     SQL> ATTACH 'FILENAME personnel';
>     This database context has already been declared.
>     Would you like to override this declaration (No)? Y
>     SQL>
>     SQL> -- Now warring cannot insert new rows into the EMPLOYEES table:
>     SQL> INSERT INTO EMPLOYEES (EMPLOYEE_ID) VALUES ("99999");
>     %RDB-E-NO_PRIV, privilege denied by database facility
>     SQL>
>     SQL> -- A GRANT statement gives all privileges back to warring:
>     SQL> GRANT ALL ON TABLE EMPLOYEES TO warring;
>     SQL> COMMIT;

> 例2: SQLコマンド・ファイルを使用したACLの作成

> 次のSQLコマンド・ファイルでは、デフォルトの別名RDB$DBHANDLEを指定して、デフォルト・データベースのACLを作成します。ACLエントリの順序付けには、次の2つの一般的ガイドラインを使用します。

> - ユーザー識別子の制限が少ないほど、リストでACLは低くなります。

> - 権限が強力であるほど、リストでACLは高くなります。

> SQLではリストを上から下まで読み取るため、特定の識別子があるエントリを前に、一般的な識別子があるエントリを後ろに配置する必要があります。たとえば、最も一般的なユーザー識別子[*,*]をリストの最初に配置すると、すべてのユーザーがそれに一致し、Oracle Rdbはそこに指定されたすべてのアクセス権をすべてのユーザーに付与または拒否します。

> 同様に、一般エントリ[admin,*]を特定エントリ[admin,ford]の前に配置すると、SQLではユーザー[admin,ford]が[admin,*]に一致し、ユーザー[admin,ford]が必要とするアクセス権INSERT、UPDATEおよびDELETEが拒否されます。

>     -- Database Administrator -- needs all privileges.
>     --
>          GRANT ALL
>          ON DATABASE ALIAS RDB$DBHANDLE
>          TO [group2,adams]
>          POSITION 1;

>     -- Assistant -- needs to be able to use data definition statements.
>     --
>          GRANT SELECT,CREATE,ALTER,DROP
>          ON DATABASE ALIAS RDB$DBHANDLE
>          TO [group2,clark]
>          POSITION 2;

>     -- Operator -- needs to be able to perform database maintenance tasks.
>     --
>          GRANT SELECT, ALTER, DBADM
>          ON DATABASE ALIAS RDB$DBHANDLE
>          TO [group2,lawrence]
>          POSITION 3;

>     -- Security Administrator -- needs to specify and show security events
>     -- audited for a database and review the audit trail.
>     --
>          GRANT SECURITY
>          ON DATABASE ALIAS RDB$DBHANDLE
>          TO [group2,davis]
>          POSITION 4;

>     -- Manager -- needs to be able to use all data manipulation statements.
>     --
>          GRANT SELECT,INSERT,UPDATE,DELETE
>          ON DATABASE ALIAS RDB$DBHANDLE
>          TO [admin,smith]
>          POSITION 5;

>     -- Secretary -- needs to be able to read, write, and delete data.
>     -- No access to data definition or maintenance.
>     --
>          GRANT SELECT,INSERT,UPDATE,DELETE
>          ON DATABASE ALIAS RDB$DBHANDLE
>          TO [admin,ford]
>          POSITION 6;

>     -- Programmers -- need to perform data definition and data manipulation
>     -- on some tables and constraints to test application programs.
>     --
>          GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,ALTER,DROP,REFERENCES
>          ON DATABASE ALIAS RDB$DBHANDLE
>          TO PROGRAMMERS
>          POSITION 7;

>     -- Clerks -- need to be able only to read data. No access to modify, erase,
>     -- store, data definition, or maintenance statements.
>     --
>          GRANT SELECT
>          ON DATABASE ALIAS RDB$DBHANDLE
>          TO [admin,*]
>          POSITION 8;

>     -- Deny access to all users not explicitly granted access to the database.
>     --
>          REVOKE ALL
>          ON DATABASE ALIAS RDB$DBHANDLE
>          FROM PUBLIC
>          POSITION 9;

> 例3: 列アクセス権の付与および表アクセス権の拒否

> 特定の列に影響する制約を定義するには、REFERENCES権限が必要です。列のデータを更新するには、UPDATE権限が必要です。表に対するUPDATE権限のあるユーザーは、表のすべての列に対して自動的にUPDATE権限を受領します。列を更新するには、列または表に対するUPDATE権限が必要です。ただし、データベース管理者は、ユーザーによる更新が可能な列のみを定義し、表エントリからUPDATE権限を削除することによって制限できます。現行給与は機密情報であるため、この額を更新する機能の制限が必要な場合があります。

> 次の例では、ユーザー[admin,ford]が、SALARY_STARTおよびSALARY_ENDを除くSALARY_HISTORY表の列を更新できないようにします。たとえば、ユーザー[admin,ford]は、SALARY_AMOUNT列を更新できません。

>     SQL> GRANT UPDATE ON COLUMN SALARY_HISTORY.SALARY_START
>     cont> TO [admin,ford];
>     SQL> GRANT UPDATE ON COLUMN SALARY_HISTORY.SALARY_END
>     cont> TO [admin,ford];
>     SQL> --
>     SQL> REVOKE UPDATE ON TABLE SALARY_HISTORY FROM [admin,ford];
>     SQL> --
>     SQL> COMMIT;
>     SQL> --
>     SQL> SHOW PROTECTION ON TABLE SALARY_HISTORY;
>     Protection on Table SALARY_HISTORY
>         (IDENTIFIER=[grp2,jones],ACCESS=SELECT+INSERT+UPDATE+DELETE+SHOW+CREATE+
>          ALTER+DROP+DBCTRL+DBADM+REFERENCES+SECURITY+DISTRIBTRAN)
>         (IDENTIFIER=[*,*],ACCESS=NONE)
>     SQL> --
>     SQL> SHOW PROTECTION ON COLUMN SALARY_HISTORY.SALARY_START;
>     Protection on Column SALARY_HISTORY.SALARY_START
>         (IDENTIFIER=[admin,ford],ACCESS=UPDATE)
>         (IDENTIFIER=[*,*],ACCESS=NONE)

> 例4: すべてのユーザーへの順序に対するSELECT権限の付与

>     SQL> SHOW PROTECTION ON SEQUENCE EMPID
>     Protection on Sequence EMPID
>         (IDENTIFIER=[RDB,STRAUTS],ACCESS=SELECT+SHOW+ALTER+DROP+DBCTRL)
>         (IDENTIFIER=[*,*],ACCESS=NONE)
>     SQL> GRANT SELECT ON SEQUENCE EMPID TO PUBLIC;
>     SQL> SHOW PROTECTION ON SEQUENCE EMPID;
>     Protection on Sequence EMPID
>         (IDENTIFIER=[RDB,STRAUTS],ACCESS=SELECT+SHOW+ALTER+DROP+DBCTRL)
>         (IDENTIFIER=[*,*],ACCESS=SELECT)

> 例5: ロールに対するINSERT ON TABLE権限の付与

>     SQL> SHOW PROTECTION ON TABLE JOBS
>     Protection on Table JOBS
>         (IDENTIFIER=[250,254],ACCESS=SELECT+INSERT+UPDATE+DELETE+SHOW+CREATE+ALTER+
>           DROP+DBCTRL+DBADM+REFERENCES)
>         (IDENTIFIER=PUBLIC,ACCESS=SELECT+INSERT+UPDATE+DELETE+SHOW+CREATE+ALTER+DROP
>           +DBADM+REFERENCES)
>     SQL> CREATE ROLE ADMINISTRATOR;
>     SQL> GRANT INSERT ON TABLE JOBS TO ADMINISTRATOR AFTER [250,254];
>     SQL> SHOW PROTECTION ON TABLE JOBS
>     Protection on Table JOBS
>         (IDENTIFIER=[250,254],ACCESS=SELECT+INSERT+UPDATE+DELETE+SHOW+CREATE+ALTER+
>           DROP+DBCTRL+DBADM+REFERENCES)
>         (IDENTIFIER=ADMINISTRATOR,ACCESS=INSERT)
>         (IDENTIFIER=PUBLIC,ACCESS=SELECT+INSERT+UPDATE+DELETE+SHOW+CREATE+ALTER+DROP
>           +DBADM+REFERENCES)

> 例6: ユーザーへのすべてのアクセス権の許可

>     SQL> -- Allow all access to user JAIN
>     SQL> GRANT SELECT ON DATABASE ALIAS *   to jain;
>     SQL> GRANT SELECT ON TABLE *            to jain;
>     SQL> GRANT EXECUTE ON MODULE *          to jain;
>     SQL> GRANT EXECUTE ON PROCEDURE *       to jain;
>     SQL> GRANT EXECUTE ON FUNCTION  *       to jain;

> 例7: 権限の付与時におけるユーザーの自動作成

>     SQL> ATTACH 'FILENAME MF_PERSONNEL.RDB';
>     SQL> SHOW USERS
>     Users in database with filename mf_personnel.rdb
>          tsmith
>          jstuart
>     SQL> GRANT ALL ON DATABASE ALIAS RDB$DBHANDLE TO CDAY;
>     %RDB-W-META_WARN, metadata successfully updated with the reported warning
>     -RDMS-W-PRFCREATED, some users or roles were created
>     SQL> SHOW USERS
>     Users in database with filename mf_personnel.rdb
>          tsmith
>          jstuart
>          cday