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     *                    //...

プロキシとプロテクション

HelixプロキシユーザのワークステーションのIPアドレスをプロテクションテーブルに対して適用するには、ワークステーションの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以降になっている必要があります。

権限サブフィールド

以下の表で、権限サブフィールドについて説明します。

アクセスレベル

アクセスレベルは各行の先頭に記述されます。 権限レベルおよびアクセス権限を以下の表に示します。

各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アドレスが合致するプロテクション行のマッピングの組み合わせにより定義されます。 (排他的プロテクションが使用されている場合、この動作は若干異なりますが、これについては次のセクションで説明します)。

read      user    *        195.42.39.17     //...
write     user    lisag    195.42.39.17     //depot/elm_proj/doc/...
read      user    lisag    *                //...
super     user    edk      *                //...

プロテクションテーブルの一部の管理を委任する

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アドレスに関するすべてのアクセスが拒否されます。 排他的プロテクションで指定されるアクセスレベルは意味を持ちません。 詳細については、「プロテクションの実装のしくみ」を参照してください。
• 除外マッピングを使用しない場合、プロテクションテーブルの項目の順番は重要ではありません。

write       user       *           *       //...
read        user       emily       *       //depot/elm_proj/...
super       user       joe         *       -//...
list        user       lisag       *       -//...
write       user       lisag       *       //depot/elm_proj/doc/...

ユーザ、グループまたはパスに設定されたプロテクションの表示

p4 protectsコマンドを使用して、ユーザやグループまたはファイルセットに適用されるプロテクションテーブルの行を表示することができます。

オプションを指定しない場合、p4 protectsは現在のユーザに適用されるプロテクションテーブル内の行を表示します。 file引数が指定された場合、該当ファイルに適用されるプロテクションテーブル内の行のみが表示されます。 -mフラグを使用すると、除外マッピングを無視したうえで、適用可能な最大アクセスレベルの概要が一語で表示されます。

Helixサーバスーパーユーザはp4 protects -aを使用して全ユーザの行を表示したり、p4 protects -u user、-g group、または-hhostの各フラグを使用して特定のユーザ、グループ、ホストIPアドレスの行を表示したりすることができます。

-sオプションを使用すると、spec引数で指定されたファイルリビジョンによって参照されたプロテクトテーブルからプロテクション情報を表示します。 例えば、以下のコマンドは3番目のプロテクションテーブルのユーザであるサムについての情報を返します。

C:\> p4 -u super protects -s //spec/protect.p4s#3 -u sam
write user* * //...

これは、ある時点でユーザがアクセス権限を失った場合に、その日付の前にプロテクションテーブルに対して行われた変更を確認するのに便利です。