我被要求查看如何限制ClearCase中某些VOB的读取访问权限，这是出于合规性原因（因此需要进行审计，等等......）。到目前为止我找到了一个解决方案，我将在这里发布，但我仍然有疑问，所以任何帮助都会受到赞赏。特别是在细节中，我认为是魔鬼。
为了便于论证，我们假设有3个VOB和3个组：
未回答的问题：
为CC用户设置不同的域组有什么影响？当人们记录时，他们的clearcase组由用户变量CLEARCASE_PRIMARY_GROUP获取。如果他们来自gA并且正在vA中正常工作，那么这个变量将被设置为gA，但是如果他们需要在vC中更改某些内容，我敢打赌他们在vC中的文件/版本的组所有权将保留为gA什么都不做。 vC中的对象最终将拥有属于gA，gB，gC的组。这可能是个问题吗？
我甚至不确定是否可以在vB上正确设置ACL而不实际创建一个新组，gA'包含来自gA和gB的人，我是对的吗？
在我看来，这里的困难不是技术性的，而是在向特定群体提供某些人访问的过程中，并且CM团队应该远离这一点（并留下它由安全部门和相关的开发团队决定）。任何人都有这方面的经验吗？
似乎可以使用ClearCase Regions来实现相同的效果。如何运作？
致以最诚挚的问候，
托马斯
答案 0 :(得分：1)
为CC用户设置不同的域组有什么影响？
除了管理成本之外没有（将每个用户注册到许多组可能很麻烦） 拥有不同组的多个元素的事实本身并不是问题。
VOB vB，对组gB的读/写访问权限，对组gA的读访问权限，以及限制为其他所有人
gB是vB的二级组的一部分，gA不是（意味着不可以结账） 770用于系统组，包括gA和gB（表示gA的读取访问权限，gB读取/写入，gC拒绝）
只读或读/写意味着通过clearcase（“cleartool protect”或“cleartool protectvob”）设置的保护，但“无法访问”只能在系统上实现 level（chmod 770）
ClearCase区域与数据限制无关，只与数据可见性有关：它只允许您查看vob或视图的子集，它不会阻止您访问它们（简单的mktag -vob，您会看到无论如何，“机密”vob）
在我看来，这里的困难不是技术性的，而是在向特定群体提供某些人的访问权限的过程中，并且CM团队应该远离这一点（并由此决定安全部门和参与的开发团队。）
叹息...... CM应该远离，但CM团队不能总是远离;）该团队必须至少初始化请求，以便系统团队在正确的组中注册用户。与具有自己的组管理系统的VCS相比，单独的初始化步骤是相当大的阻力。但是ClearCase还没有。
答案 1 :(得分：0)
到目前为止，我找到了this answer from the IBM developerworks forums：
（编辑）的
为团队创建另外两个域组
将相应的新域组添加到每个ClearCase用户的组配置文件中（除了他们已有的gC组成员身份）。 您希望vobadmin帐户成为这两个新组的成员。
相应地更改VOB的组所有权：
cleartool protectvob -chgrp group_name <\\..vob.vbs>
适用于vA的gA gB for vB
所有其他VOB的gC（应该已经是这种情况）从根元素中删除“其他组”权限 vA和vB VOB：
cleartool protect -chmod 770 <vob-tag-name>
您也可以使用CC Explorer执行此操作：右键单击VOB中的 任何视图并选择“元素的属性”。没有必要 重新保护整个VOB（注意：这对我来说很重要，因为重新保护整个VOB需要很长时间，而且我这里有超过200个VOB。）现在，只有gA组的成员才能访问vA VOB 只有gB组的成员才能访问vB VOB 每个人都是gC小组的成员，所以每个人都可以访问所有人 其他VOB。
请注意，您需要设置CLEARCASE_PRIMARY_GROUP环境 如果您想要新创建的对象，则为特定用户的变量 用户由与该用户帐户的主要组不同的组拥有 因为它在域控制器中设置。