GRANT
GRANT ステートメントにより、新規のユーザー ID を作成し、セキュリティで保護されているデータベース内の特定のユーザーに権限を付与します。
構文
GRANT CREATETAB | CREATEVIEW | CREATESP TO
public またはユーザー/グループ名[, ユーザー/グループ名]...
GRANT LOGIN TO ユーザーおよびパスワード[, ユーザーおよびパスワード]
...[IN GROUP グループ名]
GRANT 権限 ON < * | [TABLE] テーブル名 [オーナー ネーム] |
VIEW ビュー名 | PROCEDURE ストアド プロシージャ名 >
TO ユーザー/グループ名[, ユーザー/グループ名]...
* ::= すべてのオブジェクト（つまり、すべてのテーブル、ビュー、およびストアド プロシージャ）
権限 ::= ALL
| ALTER
| DELETE
| INSERT [(テーブルの列名[, テーブルの列名]...)]
| REFERENCES
| SELECT [(テーブルの列名[, テーブルの列名]...)]
| UPDATE [(テーブルの列名[, テーブルの列名]...)]
| EXECUTE
テーブル名 ::= ユーザー定義のテーブル名
オーナー ネーム ::= ユーザー定義のオーナー ネーム
ビュー名 ::= ユーザー定義のビュー名
ストアド プロシージャ名 ::= ユーザー定義のストアド プロシージャ名
ユーザーおよびパスワード ::= ユーザー名[:]パスワード
public またはユーザー/グループ名 ::= PUBLIC | ユーザー/グループ名
ユーザー/グループ名 ::= ユーザー名 | グループ名
ユーザー名 ::= ユーザー定義のユーザー名
テーブルの列名 ::= ユーザー定義の列名（テーブルのみ）
備考
CREATETAB、CREATESP、CREATEVIEW、および LOGIN TO 引数は、コア SQL 文法の拡張機能です。GRANT ステートメントを使用して、CREATE TABLE、CREATE VIEW、および CREATE PROCEDURE に権限を付与し、既に作成済みのグループのメンバーとしてパスワード付きのユーザー アカウントを作成することができます。
次の表は、特定の操作に対する構文を示しています。
この操作に権限を付与する場合 | GRANT で使用する構文 |
CREATE TABLE | CREATETAB |
CREATE VIEW | CREATEVIEW |
CREATE PROCEDURE | CREATESP |
LOGIN AS GROUP MEMBER | LOGIN TO |
ここで留意する点は、CREATETAB、CREATEVIEW、および CREATESP は明示的に付与する必要があるということです。これらの権限は、GRANT ALL ステートメントの一部として含まれません。
GRANT LOGIN TO
GRANT LOGIN TO はユーザーを作成し、そのユーザーにセキュリティで保護されたデータベースへのアクセスを許可します。ユーザーを作成するには、ユーザー名とユーザー パスワードを指定する必要があります。任意で、ユーザーが属するグループを指定することもできます。これは既存のグループでなければなりません。GRANT LOGIN ステートメントでグループを作成することはできません。
制約
権限には次の制約が適用されます。
オブジェクトの種類別
表 32 オブジェクトの種類に適用される権限
権限 | テーブル1 | ビュー1 | ストアド プロシージャ |
CREATETAB | | | |
CREATEVIEW | | | |
CREATESP | | | |
ALTER2 | | | |
DELETE | | | |
INSERT | | | |
REFERENCES | | | |
SELECT | | | |
UPDATE | | | |
EXECUTE3 | | | |
1 列はテーブルに対してのみ指定できます。ビューの権限はビュー全体に対して付与することはできますが、ビュー内の個々の列に対して付与することはできません。 2 テーブル、ビュー、またはストアド プロシージャを削除するには、ユーザーは対象オブジェクトの ALTER 権限を持っている必要があります。信頼されるビューおよびストアド プロシージャを削除できるのは、Master ユーザーのみです。 3 EXECUTE 権限はストアド プロシージャにのみ適用されます。ストアド プロシージャを実行できるのは、CALL ステートメントまたは EXECUTE ステートメントのいずれかである点に注意してください。ストアド プロシージャは、信頼されるタイプでも信頼されないタイプでもかまいません。 信頼されるオブジェクトと信頼されないオブジェクトを参照してください。 |
ALL キーワード
表 33 ALL キーワードによって付与される権限（オブジェクトの種類別）
ALL によって含まれる権限 | テーブル | ビュー | ストアド プロシージャ |
ALTER1 | | | |
DELETE | | | |
INSERT | | | |
REFERENCES | | | |
SELECT | | | |
UPDATE | | | |
EXECUTE | | | |
1 テーブル、ビュー、またはストアド プロシージャを削除するには、ユーザーは対象オブジェクトの ALTER 権限を持っている必要があります。信頼されるビューおよびストアド プロシージャを削除できるのは、Master ユーザーのみです。 |
たとえば、次のように発行した場合 - GRANT ALL ON * to User1、User1 は上の表に挙げられているすべての権限を持ちます。
GRANT ALL ON VIEW myview1 TO User2 を発行した場合は、User2 は myview1 の ALTER、DELETE、INSERT、UPDATE、および SELECT 権限を持ちます。
ユーザーとグループ
リレーショナル セキュリティは、セキュリティをオンにしたときに、データベースヘのフル アクセス権を持つ "Master" という名前のデフォルト ユーザーが存在するかどうかに基づきます。セキュリティを有効にすると、Master ユーザーにパスワードの指定が必要になります。
このステートメントを実行するには、セキュリティ設定が有効になっている必要があります。
Master ユーザーは、GRANT LOGIN TO、CREATE USER、または CREATE GROUP コマンドを使用してグループやほかのユーザーを作成したり、作成したグループやユーザーにデータ アクセス権限を定義することができます。
すべてのユーザーに同一の権限を付与したい場合は、PUBLIC グループに権限を付与します。すべてのユーザーは、PUBLIC グループに割り当てられているデフォルトの権限を継承します。
メモ： グループを使用する場合は、ユーザーを作成する前にグループを設定する必要があります。
ユーザー名とパスワードに空白またはその他の非英数文字が含まれる場合は、ユーザー名とパスワードを二重引用符で囲む必要があります。
ユーザーとグループの詳細については、『
Advanced Operations Guide』の
Master ユーザーおよび
ユーザーとグループを参照してください。
オーナー ネーム
オーナー ネームは、Btrieve ファイルのアクセスを得るために必要なパスワードです。オーナー ネームとシステム ユーザー名あるいはデータベース ユーザー名との間に関連はありません。オーナー ネームは、単なるファイル パスワードと考えてください。
セキュリティで保護されている ODBC データベース内のテーブルであるファイルに Btrieve オーナー ネームを設定する場合、その ODBC データベースの Master ユーザーはすべての GRANT ステートメントでオーナー ネームを使用して、指定されたテーブルの権限を Master ユーザーを含む全ユーザーに付与しなければなりません。
オーナー ネームを含む
GRANT ステートメントがある指定ユーザーに対し発行されたら、そのユーザーはアクセスのたびにオーナー ネームを指定しなくても、データベースにログインすることで指定されたテーブルにアクセスできるようになります（また、SET OWNER ステートメントを使用すると、現在のデータベース接続中に使用するオーナー ネームを 1 つまたは複数指定できることに注意してください。
SET OWNER を参照してください）。
ユーザーが Btrieve オーナー ネームを持つテーブルに ODBC 経由でアクセスしようとした場合、Master ユーザーが GRANT ステートメントで正しいオーナー ネームを使ってそのユーザーにテーブル権限を付与していない限り、アクセスは許可されません。
テーブルが読み取り専用属性のオーナー ネームを持つ場合は、オーナー ネームを含む SELECT 権限を Master ユーザーに明確に付与しなくても、Master ユーザーは自動的にこのテーブルの SELECT 権限を持ちます。
ビューおよびストアド プロシージャに対する権限
ビューおよびストアド プロシージャは、そのビューまたはストアド プロシージャによって参照されるオブジェクトに対してどのように権限を処理したいかに応じて、信頼されるものでも信頼されないものでも指定できます。
信頼されるオブジェクトと信頼されないオブジェクト
ビューおよびストアド プロシージャは、テーブルやその他のビュー、その他のストアド プロシージャなどのオブジェクトを参照します。参照されるオブジェクトごとに権限を付与することは、オブジェクトとユーザーの数に応じて、非常に時間のかかるものとなります。多様な状況に合ったより簡潔な解決法として、信頼されるビューまたは信頼されるストアド プロシージャという概念があります。
信頼されるビューまたはストアド プロシージャとは、参照されるオブジェクトごとに権限を明示的に設定しなくても実行できるものです。たとえば、信頼されるビュー "myview1" がテーブル "t1" と "t2" を参照している場合、Master ユーザーは "t1" および "t2" にユーザー権限を付与しなくても "myview1" にユーザー権限を付与することができます。
信頼されないビューまたはストアド プロシージャとは、参照されるオブジェクトごとに権限を明示的に設定しなければ実行できないものです。
信頼されるオブジェクトと信頼されないオブジェクトの特性の比較については、次の表を参照してください。
表 34 信頼される/信頼されないビューおよびストアド プロシージャの特性
オブジェクト | 特性 | 注記 |
信頼されるビューまたは信頼されるストアド プロシージャ | メタデータ バージョン 2 を必要とします | |
CREATE ステートメントに WITH EXECUTE AS 'MASTER' 句を必要とします | |
Master ユーザーのみがオブジェクトを作成できます | 『 Advanced Operations Guide』の Master ユーザーを参照してください。 |
Master ユーザーのみがオブジェクトを削除できます | |
Master ユーザーはほかのユーザーにオブジェクト権限を付与する必要があります | デフォルトでは、Master ユーザーのみが信頼されるビューまたはストアド プロシージャにアクセスできるので、Master ユーザーがこれらのオブジェクトにユーザー権限を付与しなければなりません。 |
GRANT および REVOKE ステートメントはオブジェクトに適用されます | |
オブジェクトは、セキュリティで保護されたデータベースまたは保護されていないデータベースに存在することができます | 『 Advanced Operations Guide』の セキュリティ モデルと概念を参照してください。 |
信頼されるオブジェクトを信頼されないオブジェクトに変更する（またはその逆）には、オブジェクトを削除してから再作成する必要があります | ビューやストアド プロシージャ用の ALTER ステートメントを使用して、オブジェクトの信頼に関する特性の追加、削除を行うことはできません。信頼されるオブジェクトを信頼されないオブジェクトに変更しなければならない場合は、まずそのオブジェクトを削除してから、WITH EXECUTE AS 'MASTER' 句を指定しないでオブジェクトを作り直します。同様に、信頼されないオブジェクトを信頼されるオブジェクトに変更しなければならない場合は、まずそのオブジェクトを削除してから、WITH EXECUTE AS 'MASTER' 句を指定してオブジェクトを作り直します。 |
信頼されないビューまたは信頼されないストアド プロシージャ | 任意のユーザーがオブジェクトを作成できます | ユーザーには CREATEVIEW または CREATESP 権限が付与されている必要があります。 備考を参照してください。 |
任意のユーザーがオブジェクトを削除できます | ユーザーには、ビューまたはストアド プロシージャに対する ALTER 権限が付与されている必要があります。 GRANT を参照してください。 |
オブジェクトを削除するには ALTER 権限が必要となります | ALTER 権限は、テーブルを削除する場合にも必要です。デフォルトでは、Master ユーザーのみが信頼されるオブジェクトを削除できることに注意してください。ビューまたはストアド プロシージャの作成者でない（Master 以外の）ユーザーがビューやストアド プロシージャを削除するには、ALTER 権限が付与されている必要があります。 |
デフォルトで、すべてのユーザーはオブジェクトに対するすべての権限を持っています | メタデータ バージョン 2 では、セキュリティで保護されていないデータベースに信頼されないオブジェクトが含まれている場合、データベースのセキュリティを有効にすれば、信頼されないオブジェクトのすべての権限は自動的に PUBLIC に付与されます。 |
ビューまたはストアド プロシージャを実行するユーザーは、これらから参照されるオブジェクトの権限を必要とします | ユーザーは、最上位のオブジェクトに対する権限も持っている必要があります。つまり、ほかのオブジェクトを参照するビューやストアド プロシージャに対する権限ということです。 |
GRANT および REVOKE ステートメントはオブジェクトに適用されます | GRANT および REVOKE を参照してください。 |
オブジェクトは、セキュリティで保護されたデータベースまたは保護されていないデータベースに存在することができます | 『 Advanced Operations Guide』の セキュリティ モデルと概念を参照してください。 |
信頼されるオブジェクトを信頼されないオブジェクトに変更する（またはその逆）には、オブジェクトを削除してから再作成する必要があります | 前述の、信頼されるビューまたは信頼されるストアド プロシージャの場合と同様です。 |
例
GRANT ALL ステートメントは、指定したユーザーまたはグループに INSERT、UPDATE、ALTER、SELECT、DELETE、および REFERENCES の権限を付与します。また、辞書の CREATE TABLE 権限も付与されます。次のステートメントによって、テーブル Class のユーザー dannyd に上記のすべての権限が付与されます。
GRANT ALL on Class to dannyd
============
次のステートメントによって、テーブル Class のユーザー debieq に ALTER 権限が付与されます。
GRANT ALTER on Class TO debieq
============
次のステートメントによって、テーブル Class の keithv および miked に INSERT 権限が付与されます。このテーブルは winsvr644AdminGrp というオーナー ネームを持ちます。
GRANT INSERT ON Class winsvr644AdminGrp TO keithv, miked
============
次のステートメントによって、テーブル Class の keithv および miked に INSERT 権限が付与されます。
GRANT INSERT ON Class TO keithv, miked
============
次のステートメントによって、ユーザー keithv および brendanb に Person テーブル内の 2 つの列 First_name と Last_name の INSERT 権限が与えられます。
GRANT INSERT(First_name,last_name) ON Person to keithv,brendanb
============
次の例は、ユーザー aideenw および punitas に CREATE TABLE 権限を与えます。
GRANT CREATETAB TO aideenw, punitas
============
次の GRANT LOGIN TO ステートメントは ravi という名前のユーザーにログイン権限を与え、パスワード password を指定します。
GRANT LOGIN TO ravi:password
メモ： GRANT LOGIN TO ステートメントを使用してログイン権限を与えられたユーザー アカウントが現存しない場合、そのユーザー アカウントが作成されます。
ストアド プロシージャで GRANT LOGIN ステートメントを使用する場合は、ユーザー名とパスワードをコロンではなく空白文字で区切る必要があります。コロン文字は、ストアド プロシージャ内でローカル変数の識別に使用されます。
このユーザー名およびパスワードは Pervasive PSQL データベースのみを対象としたもので、オペレーティング システム レベルで設定されているユーザー名とパスワードには無関係です。Pervasive PSQL ユーザー名、グループ、およびパスワードは Pervasive PSQL Control Center（PCC）を使用して設定することもできます。
次の例では、dannyd と travisk という名前のユーザーにログイン権限が与えられ、パスワードがそれぞれ password、1234567 と指定されます。
GRANT LOGIN TO dannyd:password,travisk:1234567
名前に空白が含まれる場合は、次のように二重引用符を使用できます。このステートメントによって、Jerry Gentry と Punita という名前のユーザーにログイン権限が与えられ、パスワードがそれぞれ sun、moon と指定されます。
GRANT LOGIN TO ''Jerry Gentry'' :sun, Punita:moon
次の例では、パスワード 123456 を持つ Jerry Gentry という名前のユーザーと、パスワード abcdef を持つ travisk という名前のユーザーにログイン権限が与えられます。また、グループ pervasive_dev にこれらのユーザーが追加されます。
GRANT LOGIN TO ''Jerry Gentry'' :123456, travisk:abcdef in group pervasive_dev
============
Btrieve オーナー ネームを持つテーブルの権限を付与するには、Master ユーザーは GRANT ステートメントで正しいオーナー ネームを指定しなければなりません。
次の例では、Master ユーザーに Btrieve オーナー ネーム "abcd" を持つテーブル T1 の SELECT 権限が与えられます。
GRANT SELECT ON t1 'abcd' TO Master
Master ユーザーは、オーナー ネームを持たないテーブルのすべての権限を持ちます。テーブルのオーナー ネームは Maintenance ユーティリティを使って設定できます。Btrieve オーナー ネームは大小文字が区別されます。
============
Master ユーザーによる次の SQL ステートメント セットの実行後、ユーザー "jsmith" は現在のデータベース内のすべてのテーブルに対する SELECT 権を持ちます。また、ユーザーは tab1 の DELETE 権および tab2 の UPDATE 権も持ちます。
GRANT DELETE ON tab1 TO jsmith
GRANT SELECT ON * TO jsmith
GRANT UPDATE ON tab2 TO jsmith
その後、CREATE TABLE 権を持つユーザーによって次のステートメントが実行された場合、ユーザー "jsmith" は新しく作成されたテーブルの SELECT 権を持ちます。
CREATE TABLE tab3 (col1 INT)
============
GRANT CREATETAB TO user1
============
GRANT CREATESP TO user1
============
次の例では、すべてのユーザーにストアド プロシージャ cal_rtrn_rate の EXECUTE 権限が付与されます。
GRANT EXECUTE ON PROCEDURE cal_rtrn_rate TO PUBLIC
============
次の例は、Accounting グループのメンバーは employee テーブルの salary 列だけを更新できることを示しています（employee は DEMODATA サンプル データベースの一部です）。
次のようなストアド プロシージャが存在するとします。
CREATE PROCEDURE employee_proc_upd(in :EmpID integer, in :Salary money) WITH EXECUTE AS 'Master';
BEGIN
UPDATE employee SET Salary = :Salary WHERE EmployeeID = :Empid;
END
GRANT EXECUTE ON PROCEDURE employee_proc_upd TO Accounting
グループ Accounting に属するユーザーは、Employee テーブル内の saraly 以外の列を更新できないことに注目してください。これは、権限がストアド プロシージャに対してのみ付与されており、そのストアド プロシージャが saraly 列のみを更新するためです。
============
次の例では、DEMODATA サンプル データベースのセキュリティが有効で、ユーザー名 "USAcctsMgr" が追加されているものとします。ここで、そのユーザーに対し、テーブル Person の ID 列への SELECT 権を付与します。以下のステートメントを使用します。
GRANT SELECT ( ID ) ON Person TO 'USAcctsMgr'
関連項目
