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つのフィールド

各行で、個々の権限レベルまたはアクセス権限が、以下の5つのフィールドによって定義されます。

アクセスレベル

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

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

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