p4 protectによるプロテクションを設定する
p4 protect
フォームには、複数の行で構成されるProtections:
という単一のフォームフィールドが含まれています。Protections:
の各行には、下図のようにサブフィールドが設けられています。
例プロテクションテーブルの例
Protections: read user emily * //depot/elm_proj/... write group devgrp * //... write user * 192.168.41.0/24 -//... write user * [2001:db8:1:2::]/64 -//... write user joe * -//... write user lisag * -//depot/... write user lisag * //depot/doc/... super user edk * //...
(実際に表示される5つのサブフィールドは、縦の列が揃っていないことがあります。見やすくするために、ここでは縦列が揃えられています)
サイトでHelixプロキシまたはブローカを使用している場合は、ホストフィールドのアドレスの先頭にproxy-
を追加して、当該プロキシまたはブローカのユーザに各行が適用されるようにしてください。詳細については、『Helix Coreサーバ管理者ガイド: マルチサイト展開』の「P4P and protections」を参照してください。
権限の行の5つのフィールド
各行で、個々の権限レベルまたはアクセス権限が、以下の5つのフィールドによって定義されます。
フィールド | 意味 |
---|---|
|
許可または拒否するアクセスレベル(
一般的に、ユーザまたはグループごとにアクセスレベルが1つ与えられます。より細かい制御が必要であれば、1つ以上の特定の権限を拒否することができます。 |
|
プロテクションの対象が |
|
その行のプロテクションレベルが定義されているユーザまたはグループの名前を記述します。このフィールドではワイルドカード |
|
アクセスが許可されているホストのTCP/IPアドレスを記述します。このアドレスは、特定のホスト( ホストフィールドではワイルドカード プロキシマッチングを制御する場合の行頭以外では、ワイルドカード HelixサーバによるHelixプロキシへのアクセスの制御について詳しくは、『Helix Coreサーバ管理者ガイド: マルチサイト展開』の関連する章を参照してください。 |
|
権限を付与するディポのファイル仕様を指定します。指定には、Helixサーバのワイルドカードも使用できます。 " ディポが除外された場合、アクセスを拒否されたユーザは |
アクセスレベル
アクセスレベルは各行の先頭に記述されます。権限レベルおよびアクセス権限を以下の表に示します。
レベル | 意味 |
---|---|
|
|
|
|
|
この権限が拒否されている場合、ユーザはファイルに対して |
|
ディポからクライアントワークスペースへのファイルの読み込みと、それを開いて編集することが認められます。ただし、この権限では書き込みをしてファイルをディポに戻すことは認められていません。
|
|
この権限が拒否されている場合、ユーザは |
|
ファイルを編集、削除、追加するコマンドの実行が認められます。 この権限は、 |
|
この権限が拒否されている場合、ユーザは開いているファイルをサブミットできません。 |
|
この権限が拒否されている場合、ユーザは |
|
listとreadのアクセス権のほか、 |
|
特定のユーザまたはグループに、特定のパスに対して |
|
Helixサーバ管理者用です。メタデータに影響するHelixサーバコマンドの実行が許可されますが、サーバの動作に影響するコマンドの実行は許可されません。 |
|
Helixサーバスーパーユーザ用です。すべてのHelixサーバコマンドの実行が認められます。 |
各Helixサーバコマンドには、最低限必要なアクセスレベルが設定されています。例えば、あるファイルで
またはp4
sync
p4
print
を実行するには、ユーザは少なくともそのファイルへのread
のアクセス権を認められていなければなりません。各Helixサーバコマンドの実行に最低限必要なアクセスレベルの全リストについては、プロテクションの実装のしくみを参照してください。
特殊な権限である=read
、=open
、=write
、=branch
を使用して、下位のアクセスレベルを自動的に包含しないようにオーバーライドできます。これにより、個々の権限を無効にすることができます。後で下位の権限を再度付与する必要はありません。
例えば、管理者に管理コマンドの実行権限を与えつつ、ディポの特定の部分に対する変更権限を拒否したいという場合、権限テーブルを次のように設定することができます。
admin user joe * //... =write user joe * -//depot/build/... =open user joe * -//depot/build/...
この例では、ユーザjoe
は管理機能を実行でき、この権限はシステム内のすべてのディポに適用されます。admin
権限レベルでは暗黙的にそれより下位にあるすべてのアクセスレベルが認められるため、joe
は//depot/build/
を含むシステム内のどのファイルにも、開く操作、書き込み、読み取り、一覧表示が可能です。buildの階層をプロテクトするには、=write
および=open
の排他行をテーブルに追加します。ユーザjoe
は、build階層にあるすべてのファイルを編集目的で開くことができなくなります。また、既に開いている可能性のある、この階層で加えられた変更はサブミットできません。ファイルの作成および変更は引き続き可能ですが、プロテクトされた階層//depot/build/...
の外にそれらのファイルがある場合に限られます。
デフォルトのプロテクション
p4 protect
が呼び出されるまでは全ユーザがsuperユーザの特権をもっています。初めてp4 protect
を実行すると、デフォルトで2つの権限が設定されます。デフォルトのプロテクションテーブルは次のように表示されます。
write user * * //... super user edk * //...
これは、全ホストの全ユーザに全ファイルへのwrite
アクセス権を認め、最初にp4 protect
を呼び出したユーザ(この場合はedk
)にsuperユーザの特権を認めることを示しています。
各ユーザに認める権限を決める
最も単純なアクセスレベルの割り当て方は、Helixサーバシステムを管理する必要のないユーザ全員にwrite
のアクセス権、管理するユーザにsuper
のアクセス権を与える方法ですが、このような単純な方法では不十分な場合があります。
個々のファイルについて編集する必要のないユーザに関しては、特定ファイルに対するReadのアクセス権を認める方が望ましいでしょう。例えば、エンジニアなら、ソースファイルに対するwrite
権限はあっても、文書ファイルに対しては、read
アクセス権のみで十分な場合があります。また、コードを扱わないマネージャもすべてのファイルについてread
アクセス権で充分な場合があります。
open
のアクセス権はファイルのローカル編集を可能にしますが、書き込みとディポへのサブミットは認めないので、特殊な状況でのみopen
アクセス権を指定します。ユーザがローカルで変更をテストしても、その変更を他のユーザに見せる必要がない場合には、open
アクセス権ではなくwrite
アクセス権を与えます。例えば、バグのテスターは特定のバグが発生する理由について理論をテストするためにコード変更が必要な場合がありますが、そのような変更はディポに書き込まれるべきではありません。大抵の場合、コードラインはそのままにしておき、開発チームによる入念なレビューを経て初めてローカルの変更はディポにサブミットされます。このような場合には、コード変更が承認されるまではopen
アクセス権にしておき、承認後にプロテクションレベルをwrite
に上げ、変更がサブミットされるようにします。open
アクセス権は保留を行う場合にも便利です。変更を保留するのみで変更をサブミットしない場合は、open
アクセス権を設定すれば問題ありません。この権限は、コードをレビューする場合に使用すると便利です。
権限の行が重複する場合の解釈
ユーザへのアクセス権限は、ユーザ名とクライアントIPアドレスが合致するプロテクション行のマッピングの組み合わせにより定義されます。(排他的プロテクションが使用されている場合、この動作は若干異なりますが、これについては次のセクションで説明します)。
例
リサはHelixサーバユーザ名lisag
で、IPアドレス195.42.39.17
のワークステーションを使用しています。プロテクションファイルが次のように表示されたとします。
read user * 195.42.39.17 //... write user lisag 195.42.39.17 //depot/elm_proj/doc/... read user lisag * //... super user edk * //...
このとき、リサには最初の3行の権限の組み合わせが適用されます。リサのユーザ名はlisag
です。現在、1行目と2行目で指定されたホストのクライアントワークスペースを使用しているため、ディポのサブディレクトリelm_proj/doc
のファイルには書き込みを行うことができますが、他のファイルに対しては読み取りのみを行えます。リサは以下を試みます。
「p4 edit depot/elm_proj/doc/elm-help.1
」と入力します。エラーは表示されません。
次に「p4 edit //depot/elm_proj/READ.ME
」と入力すると、適切な権限がないというエラーメッセージが表示されます。これは、read
アクセス権しか設定されていないファイルに書き込みをしようとしているためです。次に、「p4 sync depot/elm_proj/READ.ME
」と入力しますエラーは表示されません。この場合に必要になるのはread
アクセス権のみですが、この権限はファイルの1行目で指定されています。
リサは、IPアドレスが195.42.39.13
の別のマシンに切り替えます。「p4 edit
//depot/elm_proj/doc/elm-help.1
」と入力しますが、このコマンドは拒否されます。これは、このホストを使用する場合はファイルの3行目の権限のみが適用されるのに対して、ライザにはread権限しか設定されていないためです。
プロテクションテーブルの一部の管理を委任する
owner
モードでエントリを作成することにより、super権限を持っていないユーザやグループに対して、プロテクションテーブルの一部の管理を委任することができます。これらのエントリでは、ワイルドカードを使用せずに一意のパスを指定する必要があります。ただし、末尾に省略記号(…
)を指定することができます。
super
権限を持っているユーザや、パスに対するowner
権限が付与されているユーザは、許可されているパスを引数として指定してp4 protect
コマンドを実行することにより、そのパスのサブプロテクションテーブルにアクセスすることができます。
サーバは、このテーブル内のすべてのエントリをownerエントリ直下の有効なプロテクションテーブルに追加します。ownerエントリが削除されると、そのパスのサブプロテクションテーブルのエントリもすべて削除されます。ownerエントリやsuperエントリをサブプロテクションテーブルに追加することはできません。その他のエントリのパスは、サブプロテクションテーブルのパスの範囲内にある必要があります。
パス引数を指定し、それと同じパスが設定されているownerエントリが存在する場合、メインプロテクションテーブルではなく、そのパスのサブプロテクションテーブルが使用されます。
例えば、superユーザであるブルーノが次のコマンドを実行するとします。
# Create a user called Sally
$ p4 user -f sally
# Create a depot called stats
$ p4 depot stats
# Edit the protections table
$ p4 protect
最後のコマンドはエディタでプロテクションテーブルを開きます。そのプロテクションテーブルに以下の行が含まれていたとします。
Protections: write user * * //... super user bruno * //...
ブルーノがパス//stats/dev/…
のサブプロテクションテーブルの管理をサリーに委任したいとします。ブルーノはプロテクションテーブルに必要な行を追加する編集を行い、次のようになりました。
Protections: write user * * //... super user bruno * //... owner user sally * //stats/dev/...
排他的プロテクション
権限の行の5番目のフィールドの先頭にマイナス(-
)を記述すれば、ユーザのアクセスを拒否することができます。これは特定のファイルへのアクセスを大半のユーザに認めながら、ごく一部のユーザがそのファイルにアクセスするのを拒否するような場合に役立ちます。
除外マッピングを正しく活用するには、次のような特性を理解する必要があります。
- プロテクションテーブルの中に排他的プロテクションが含まれている場合には、上下の順番が意味を持ちます。排他的プロテクションは、テーブル内のその行より上の該当するプロテクションをすべて無効にします。
- 排他的プロテクションにどのようなアクセスレベルが指定されていても、該当するファイルおよびIPアドレスに関するすべてのアクセスが拒否されます。排他的プロテクションで指定されるアクセスレベルは意味を持ちません。詳細については、プロテクションの実装のしくみを参照してください。
- 除外マッピングを使用しない場合、プロテクションテーブルの項目の順番は重要ではありません。
例
管理者がp4 protect
を用いて次のようにプロテクションを設定しました。
write user * * //... read user emily * //depot/elm_proj/... super user joe * -//... list user lisag * -//... write user lisag * //depot/elm_proj/doc/...
1行目は一見、全ユーザに全ディポの全ファイルへのwriteのアクセス権を認めているようですが、下の排他的プロテクションによって、一部のユーザは除外されています。
3行目の権限はジョーについて、どのホストからのどのファイルへのアクセスも拒否します。それ以下の行でもジョーには何らのアクセスも認められていません。このため、ジョーは実質的にあらゆるファイルへのアクセスを拒否されていることになります。
4行目の権限はリサの全ホストからの全ファイルへの全アクセスを禁じていますが、5行目によって彼女には特定ディレクトリの全ファイルへのwrite
アクセス権が認められます。もし4行目と5行目が入れ替わると、リサはHelixサーバのどのコマンドも実行できなくなります。
ユーザ、グループまたはパスに設定されたプロテクションの表示
p4 protects
コマンドを使用して、ユーザやグループまたはファイルセットに適用されるプロテクションテーブルの行を表示することができます。
オプションを指定しない場合、p4 protects
は現在のユーザに適用されるプロテクションテーブル内の行を表示します。file
引数が指定された場合、該当ファイルに適用されるプロテクションテーブル内の行のみが表示されます。-m
フラグを使用すると、除外マッピングを無視したうえで、適用可能な最大アクセスレベルの概要が一語で表示されます。
Helixサーバスーパーユーザはp4 protects -a
を使用して全ユーザの行を表示したり、p4 protects -u
、-g user
group
、または-hhost
の各フラグを使用して特定のユーザ、グループ、ホストIPアドレスの行を表示したりすることができます。
-s
オプションを使用すると、spec
引数で指定されたファイルリビジョンによって参照されたプロテクトテーブルからプロテクション情報を表示します。例えば、以下のコマンドは3番目のプロテクションテーブルのユーザであるサムについての情報を返します。
C:\> p4 -u super protects -s //spec/protect.p4s#3 -u sam
write user* * //...
これは、ある時点でユーザがアクセス権限を失った場合に、その日付の前にプロテクションテーブルに対して行われた変更を確認するのに便利です。
このオプションを使用するには、プロテクトフォームにスペックディポを指定する必要があります。そうすることで、プロテクションテーブルを編集する度にリビジョンがプロテクト仕様に保存されます。スペックディポの作成方法の詳細については、『Helix Core P4コマンドリファレンス』のp4 depot
コマンドの解説を参照してください。