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プロキシユーザのワークステーションのIPアドレスをプロテクションテーブルに対して適用するには、ワークステーションのIPアドレスの先頭にproxy-
という文字列を追加します。
ワークステーションのIPアドレスの先頭に文字列proxy-
を追加する前に、ブローカまたはプロキシが配置されていることを確認します。
例えば、192.168.10.0/24
というサブネット上のワークステーションでリモート開発を行っている組織を考えてみます。 この組織には、ローカル開発を行っている中央オフィスもあり、この中央オフィスは10.0.0.0/8
というサブネット上に存在しています。 Perforceサービスは10.0.0.0/8
のサブネット上にあり、Helixプロキシは192.168.10.0/24
のサブネット上にあります。 リモートサイトのユーザはremotedev
グループに属しており、時々中央オフィスにアクセスします。 各サブネットには、対応するIPv6アドレスのセットも存在しています。
remotedev
グループのメンバーが、リモートサイトでの作業時にはプロキシを使用し、ローカルサイトを使用している場合にはプロキシを使用しないようにするには、プロテクションテーブルに以下の行を追加します。
list group remotedev 192.168.10.0/24 -//... list group remotedev [2001:db8:16:81::]/48 -//... write group remotedev proxy-192.168.10.0/24 //... write group remotedev proxy-[2001:db8:16:81::]/48 //... list group remotedev proxy-10.0.0.0/8 -//... list group remotedev proxy-[2001:db8:1008::]/32 -//... write group remotedev 10.0.0.0/8 //... write group remotedev [2001:db8:1008::]/32 //...
1行目では、192.168.10.0/24
のサブネット上のワークステーションからプロキシを使用せずHelixサーバにアクセスしようと試みた場合に、remotedev
グループのすべてのユーザに対してlist
アクセスが拒否されます。 2行目では、IPv6のサブネット[2001:db8:16:81::]/48
からアクセスしようとした場合に、1行目と同じ方法でアクセスが拒否されます。
3行目では、remotedev
グループのユーザがHelixプロキシサーバを使用してサブネット192.168.10.0/24
から作業している場合に、このグループ内のすべてのユーザに対してwrite
アクセスが許可されます。 リモートサイトにあるワークステーションのユーザは、プロキシを使用しなければなりません。 (プロキシサーバ自体がこのサブネット内に存在している必要はありません。例えば、192.168.20.0
に存在していても構いません。) 4行目では、IPv6の[2001:db8:16:81::]/48
サブネットからアクセスしようとした場合に、3行目と同じ方法でアクセスが許可されます。
同様に、5行目と6行目では、remotedev
ユーザが中央オフィスのサブネット(10.0.0.0/8
と[2001:db8:1008::]/32
)上のワークステーションからプロキシを使用しようとした場合、このユーザに対してlist
アクセスが拒否されます。 7行目と8行目では、中央オフィスのサブネット上のワークステーションから直接Helixサーバにアクセスするremotedev
ユーザに対して、書き込みアクセス権限が付与されます。 remotedev
グループのユーザがローカルサイトにアクセスする場合は、Helixサーバに直接アクセスする必要があります。
Perforceサービスがプロテクションテーブルのエントリを評価する際に、dm.proxy.protects
構成可能変数も評価されます。
dm.proxy.protectsのデフォルト値は「1
」です。この場合、各種の中継サーバ(プロキシ、ブローカ、またはエッジサーバ)を経由して接続するすべてのクライアントホストのアドレスの先頭に、proxy-
というプレフィックスが追加されます。このプレフィックスは、間接的な接続であることを示しています。
dm.proxy.protects
の値を「0
」に設定すると、proxy-
プレフィックスが削除され、プロテクションエントリを1セットのみ書き込むことができるようになります。このエントリは、直接接続しているクライアントと間接的に接続しているクライアントの両方に適用されます。 これは便利ですが、中継サーバを経由して接続することに問題がある場合、安全性が低下します。 この設定を使用する場合は、すべての中継サーバがリリース2012.1以降になっている必要があります。
権限サブフィールド
以下の表で、権限サブフィールドについて説明します。
サブフィールド | 意味 |
---|---|
|
許可または拒否するアクセスレベル(
一般的に、ユーザまたはグループごとにアクセスレベルが1つ与えられます。より細かい制御が必要であれば、1つ以上の特定の権限を拒否することができます。 |
|
プロテクションの対象が |
|
その行のプロテクションレベルが定義されているユーザまたはグループの名前を記述します。 このフィールドではワイルドカード |
|
アクセスが許可されているホストのTCP/IPアドレスを記述します。 このアドレスは、特定のホスト( ホストフィールドではワイルドカード プロキシマッチングを制御する場合の行頭以外では、ワイルドカード Helixプロキシを使用してHelixサーバへのアクセスを制御する方法については、「Helixプロキシ」を参照してください。 |
|
権限を付与するディポのファイル仕様を指定します。 指定には、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/...
の外にそれらのファイルがある場合に限られます。
ストリーム仕様の権限
readstreamspec
|
この権限を持つユーザは、次のコマンドを使用してストリーム仕様を表示することができます: p4 stream -o |
=readstreamspec
|
この権限が拒否されているユーザは、次のコマンドを実行することはできません: p4 stream -o |
openstreamspec
|
この権限を持つユーザは、ストリーム仕様について、元に戻す、衝突を解決する、保留する、編集用に開く、という操作を実行することができます。 |
=openstreamspec
|
この権限が拒否されているユーザは、ストリーム仕様について、元に戻す、衝突を解決する、保留する、編集用に開く、という操作を実行することはできません。 |
writestreamspec
|
この権限を持つユーザは、ストリーム仕様のサブミットと変更を行うことができます。 |
=writestreamspec
|
この権限が拒否されている場合ユーザは、ストリーム仕様のサブミットや変更を行うことはできません。 |
任意のユーザに対してstreamspec権限が設定されている場合は、以下のような動作になります。
- streamspec権限が明示的に設定されていないユーザは、ストリーム仕様にアクセスすることはできません。
list
権限が設定されている場合は、引き続きp4 streamsを使用することができます。
任意のユーザに対してstreamspec権限が設定されていない場合は、以下のような動作になります。
-
list
、open
、write
権限により、p4 edit、p4 resolve、p4 revert、p4 shelve、p4 submit、p4 streams、p4 streamコマンドに対するストリーム仕様のアクセスが制御されます。 list
権限により、p4 streams
コマンドでストリーム仕様のパスにアクセスすることができます。
open
以上の権限が設定されているユーザは、すべてのストリーム仕様について、edit
権限とwrite
権限が付与されます。
デフォルトのプロテクション
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
コマンドの解説を参照してください。