バージョン 8.0 以前の ClearCase のリリースでは、VOB エレメントにはそれぞれ owner、group、other という 3 つの保護カテゴリがあります。 管理者は各カテゴリに対して、読み取りビットおよび実行ビットの設定または消去を行うことができます。例えば、所有者とエレメント グループのメンバーに対しては読み取り可能にするが、ネットワークのすべてのユーザーには読み取り不可にするべきソース ファイルがある場合は、owner=read、group=read、other=none と設定します。特定のプログラミング ツール向けの実行可能ファイルがある場合は、3 つすべてのカテゴリを read および execute に設定することができます。
実際には、このモデルでは、同一の保護を共有する複数のエレメントの各クラスごとに、1 つの個別のグループを使用する必要があります。 VOB 内のエレメントの読み取りをすべてのユーザーに許可しない場合は、other=none と設定し、owner カテゴリと group カテゴリを使用してアクセスを制御する必要があります。
エレメント保護の点で、エレメント所有者の有用性は限られているため、制御を行うにはグループのみが有効な手段となります。 デフォルトでは、エレメント所有者は、そのエレメントを作成したユーザー アカウントに設定されています。 複数の開発者がいる場合、エレメントの所有者が変化する可能性があるため、アクセス制御の面で不便になります。エレメント作成後に所有権を VOB 所有者アカウントに変更するようにトリガーを構成する管理者もいますが、ほとんどのユーザーは VOB 所有者の識別情報を引き受けることはまれであるため、これもアクセス制御の点で不便です。
これが原因で、エレメントのグループは、各エレメントへのアクセスを制御するメカニズムにとどまっています。 管理者は、保護が必要なエレメントの各クラスに対して別個のグループを定義する必要があります。 例えば、エレメント クラス 1 がコンポーネント A の開発者用で、エレメント クラス 2 がコンポーネント B の開発者用で、エレメント クラス 3 がすべての開発者用 (共有コード) であるとします。 25 個のコンポーネント (A-Y) と 1 個の共有コンポーネント (Z) がある場合、アクセスの制御に 26 個のグループが必要です。コンポーネント A にあるすべてのコンポーネントを、グループ A には読み取り可能にするが、全ユーザーには読み取り可能にしないように保護します。コンポーネント B から Y にも同様にします。 コンポーネント A-Y の各開発者は対応するグループのメンバーとなり、さらにグループ Z のメンバーにもなります。すべてのコードをビルドおよび統合するのに使用されるアカウントは、すべてのグループ A-Z のメンバーである必要があります。
ClearCase が使用するグループはオペレーティング システム (Windows Domain、UNIX NIS、または LDAP) によって定義され、ClearCase を実行するホストにユーザーがログインする際に、これらのグループがそのユーザーの資格情報に追加されます。 残念ながら、オペレーティング システムおよび ClearCase で使用されるネットワーク プロトコルには制限があり、ClearCase で一度に 1 人のユーザーが使用できるグループは 16個 (UNIX および Linux)、または 32 個 (Windows) のみです。この例では、ビルド/統合のアカウントではビルドを完了するのに 26 個のグループが必要ですが、このためにはビルドの手順の複雑な順序付けおよび ClearCase 用にアクティブにするグループを定義する資格情報の変更を行ったり、エレメントのセキュリティの実装について妥協してエレメントのクラス/グループの数を少なくしたりする必要があります。どちらのオプションも望ましいものではありません。
ClearCase 8.0.1 の機能レベル 8 VOB においてエレメント保護のために ACL を使用可能にすると、アクセス制御戦略を変更して、ユーザーごとのグループ メンバーシップの制限に当てはまる可能性がある事例の数を大幅に減らすことができます。 これにより ACL は、ユーザーを複数のグループに配置するのではなく、エレメントを複数のグループに配置できるものとみなすことができます。 エレメントの有効な ACL で許可されているグループの数の制限は、ユーザー アカウントに対するグループ数ほど少なくはないため、このセキュリティ メカニズムによって、保護の新しい使用事例が可能になったり、簡単になったりします。
エレメントの ACL を使用して、複数の個別ユーザー、複数のグループ、および [everyone] といういくつかのカテゴリに、アクセス権を付与することができます。このトピックでは、有効な ACL という観点から、エレメントにおける ACL を説明します。 このトピックおよび関連するトピックでは、有効な ACL を生成するために役割マップとポリシーを組み合わせる方法を例示します。
この例では、A から Y という 25 個のコンポーネントがあり、各コンポーネントには別個のチームおよびビルド アカウント (builders) がアクセスする必要があるが、それ以外は誰からもアクセス不可にする必要がありました。 ACL を使用する場合、groupA および builders に変更の権限を付与する有効な共有 ACL を使用して、任意のコンポーネント内のすべてのエレメントを保護します。
その他の各コンポーネント B-Y には、同じように有効な ACL があります。コンポーネント Z (共有コンポーネント) にも、同じように有効な ACL があります。この構成では、チーム メンバーのアカウントは、それぞれのコンポーネントに対応するグループに加えて、Z (前に示したとおり) 用のグループにも存在します。ただし、ビルダーのアカウントが存在する必要があるのは、[builders] のグループ内のみです。 ビルダーのアカウントが複数のグループのメンバーシップに同時に存在するという制限に直面することはありません。
また、システムのビルド時に複雑な戦略を使用したり、コンポーネント A-Y のセキュリティについて妥協したりする必要もありません。グループをさらに追加したり、エレメントへ読み取り専用アクセスを追加したりする柔軟性も得ることができます。 コンポーネント Z の保守は対応するチームが行うが、チーム A-Y によって参照のみを可能にする必要があり、Z 以外の開発者を [groupZ] ではなくグループ [alldevelopers] に入れるとします。 コンポーネント Z のエレメント ACL を構成して、groupZ には変更権限、alldevelopers には読み取り権限、builders には変更権限を与えるようにします。
チーム A の開発者は、コンポーネント Z のエレメントを読み取ることはできますが、変更することはできなくなります。 (この作業を ACL を使用しないで行うには、操作を行う前にチェックアウトを行う必要があり、エレメントを変更する権限をチェックして許可されない場合は操作をリジェクトする mkbranch トリガーが必要です。)
個別のアカウントをエレメントの ACL に入れることもできます。コンポーネントへの固有のアクセスが必要な個人が数名である場合、このアクセスの目的のみのためにオペレーティング システム グループを新規作成する価値がなければ、この方法は妥当であると言えます。 このため、コンポーネント B に対応するチームとさらにもう 1 人のユーザー (extrauser) がコンポーネント B の変更を行えるようにする場合、ACL が groupB、extrauser、および builders に変更権限を付与します。
複数のチームが保守するコンポーネントがいくつかある場合、以前に使用されていたグループを除去したい場合も出てきます。 コンポーネント E の保守が、コンポーネント C および D に対応するすべてのチーム メンバーによって行われていたとします。8.0 の例では、グループ C とグループ D の両方に属するすべてのメンバーをグループ E に入れる必要がありました。ACL を使用すると、両方のグループを指定するようにコンポーネント E の ACL をセットアップしてから、グループ E の使用を中止する (チーム C および D のアカウントのグループ リストからグループ E を削除する) ことができます。
ここまでの説明は、有効な ACL という観点によるものでした。VOB では、役割マップをポリシーに適用することにより、有効な ACL が生成されます。VOB データベースは、役割マップごとに有効な ACL を計算し、キャッシュに入れます。 各エレメントは、役割マップに関連付けられます。この例を実装するには、エレメント (コンポーネント A - Z) の各クラスごとに、異なる役割マップが必要です。このすべての役割マップを、全体的な保護モデルを説明する単一のポリシーにリンクさせることができます。 ポリシーの例と、前述の有効な ACL を生成する一連の役割マップを下記に示します。 (実際には、管理ユーザーまたは管理グループを追加して、すべてのエレメントを完全に制御できるようにすることができます。)