一、VSS默认的安全访问控制
每次你安装VSS以后，系统自动激活默认的安全访问控制机制。这套机制非常简单，它包括两个等级的权限：
1. 只读权限：用户可以查看VSS数据库中的所有对象，但是不能够修改；
2. 读写权限：用户可以查看和修改VSS数据库中的任何对象。
每次你增加新用户的时候，你可以决定该用户的权限等级。在“Add User”对话框中包含一个“Read Only”复选框，你可以通过它来确定用户具有的权限。
我们前面说过这只是个极其简单、粗线条的解决方案，但同时也是最简单的。在实际过程中，你可能需要更细化的权限分配，甚至希望每个文件针对不同的用户都能设置不同的权限。那我们就得亲自动手设置我们项目的安全机制。
注意：SourceSafe中的所有安全设置都是在Visual SourceSafe Administrator中进行的，所以在深入以下细节之前，你必须确认一件事情：你的Admin密码足够安全，除你之外没有任何人可以随心所欲地进入Visual SourceSafe Administrator。否则，一切安全考虑都是徒劳。
二、项目安全与用户访问权限
在讲解项目安全之前我们先来回顾一下VSS的基本组成框架。VSS包含多个数据库（database），每个数据库又包含许多的项目，而且可能项目里嵌套着不同的子项目，最后才是你的源文件。你可以把这个类比成操作系统中的磁盘分区、目录、子目录、文件，每台机器包含许多的磁盘分区，每个分区中包含无数个目录、子目录，在子目录下才是你的文件。VSS中的用户是基于VSS数据库的，也就是说每个数据库都包含有自己的用户清单。用户访问权限意思是用户可以访问（包括查看、修改和执行命令等）数据库中的哪些项目，对项目来说就是它只能被那些已经授权的用户访问，也就是所谓的项目安全。
很遗憾VSS只提供了到项目（对应于目录）的用户权限控制，并不能针对每个文件来设置不同的用户访问权限（比如Rational ClearCase等就提供此功能）。虽然你可以用某种变通的方法来做到这一点，比如增加子项目，不过那样就破坏了整个项目结构的规范性、可读性和合理性，甚至产生些无任何意义的子项目。
VSS定义了四级用户访问权限，级别由低到高，后者包括所有前者的权限，比如说拥有Check Out权限就自动拥有了读的权限。
1. 只读（R）：允许查看文件，对应于View、Get等命令；
2. Check Out（C）：可以使用Check Out，Check In，Undo Check Out等命令修改文件内容；
3. 文件增删（A）：可以在项目中增加、删除、重命名文件或者给文件加标签，对应的命令有Add，Delete，Label，Rename等；
4. 破坏（D）：这级权限对应于那些具有巨大破坏性的操作（就是那些一不小心就可能被炒鱿鱼的操作），请牢记它们的名字：Destroy，Purge，Rollback。所以亦有人戏称之为自杀权限。
其实你可以发现默认安全机制中的两级权限是和这四者对应起来的，只不过后者把前者的读写权限细分为三个不同的级别。好啦，了解每级权限各自的含义之后我们就可以开始设置不同用户的权限啦。
设置用户权限之前，你必须激活项目安全机制。打开VSS Administrator的Tools菜单，点击“Options”得到SourceSafe Options对话框，选取“Project Security”，并且勾上“Enable project security”复选框。（如下图所示）
图1 激活项目安全机制
VSS中有三种方法可以设置用户的项目访问权限：针对项目设置每个用户的权限，针对用户设置访问每个项目的权限，拷贝用户权限，它们分别对应于Tools菜单下的Assign Rights by Project，Rights Assignments for User，Copy User Rights。我们以方法一为例做一简单说明。如下图所示，在左边框中选定项目，在右上框中选定用户，右下脚的User rights中就显示该用户现具有的权限，选中不同的复选框来设置你自己的权限。注意：对每个项目的用户权限设置自动反映到该项目的所有子项目中。
图2 用户授权
三、权限管理在实际项目中的应用
在本小节中，我主要结合在实际项目过程中作为配置管理员的经验来谈谈权限管理的实际应用，以及在应用过程中需要考虑的因素。
我们要接触的这个项目为一软件移交的项目，这个项目团队的成员组成和职责分配如下：
项目经理：1人，负责协调整个项目。
业务分析师：1人，负责整个系统业务的掌握。
系统架构师：1人，负责整个系统的系统架构。
Package Owner：3人，分别负责系统前端、中间层及后台数据库三个部分。
模块负责人：3-5人，分别负责各个模块。
数据库管理员（DBA）：1人，负责系统数据库。
Test/QA：1人，负责整个软件的测试和质量保证。
Technical Writer：1人，负责相关技术文档的写作。
变更控制委员会（CCB）：3人，负责项目需求的变更审核及执行，包括软件配置管理员，外方项目经理。
实际过程中大多会发生人员交叉现象，比如我们项目的实际人数就只有9人，项目经理又同时是CCB中的一员，Package Owner同时兼任模块负责人。根据我们项目的实际组成情况，我在VSS中给出了如下所示的项目结构：
图3 VSS项目结构
图示说明：
exec项目中主要存放项目可执行文件或者软件安装文件，由于该项目比较复杂，建立过程耗时长且比较复杂，所以直接在VSS中存放可执行文件。一般的项目不推荐这样使用。
图中只是显示整个项目结构的主要部分，省略了细节部分，比如client项目中包含有许多的小项目。
接下来，就需要为每个项目、子项目设置不同的用户访问权限。由于所有的软件重大变更都需要交由CCB审核签字后方可执行，所以我们把整个项目的D（6）级权限赋给CCB成员。而项目经理主要负责项目的整体进度的把握以及与外方项目组、其他部门的协调工作，所以拥有整个项目的R权限并且拥有development document的A权限。配置管理员的权限有两者可能，一种就是拥有整个项目的A权限，另外一种可能就是只拥有部分项目的A权限，这主要取决于赋予给配置管理员的实际权限有多大。以此类推，各个模块负责人拥有各自模块的A权限。此外由于移交项目的特殊性，一般在项目开始过程中主要以培训为主，很少涉及到软件的修改，所以建议在项目开始阶段不赋予开发工程师用户C权限以免引起不必要的错误和争论。
总结
本文通过讨论VSS中权限管理实现的具体机制，并且结合例子讲解了在实际过程中的应用。虽然移交项目有着它本身的特殊性，但我相信对于任何项目来说其安全管理的基本思路是相通的，希望此文能够给大家以一定的启示和借鉴。
参考
本文中会大量涉及到“项目”一词，有的时候它是指实际的软件项目，有时它又是指VSS数据库中的项目、子项目，请注意区分。
有关软件配置管理的更详细信息，可以参考本网站相关内容。软件配置管理主要包括版本管理、变更管理、权限管理等方面，本文主要涉及权限管理。
软件版本采用Microsoft Visual SourceSafe 6.0英文版，其他的版本请进行相应的对照。
所有这些命令的详细信息可以参考VSS帮助。
项目背景大致介绍：所移交的软件为一国外公司的软件，是基于Microsoft的DNA架构的三层应用，代码量为150万行左右。移交的目标：掌握现有系统，充分了解相关的商业逻辑，为以后开发出自己的符合中国国情的软件做好充分的准备。这其中可能涉及到需求的再分析、系统的重新架构以及向Java平台的迁移。
我们分别用R、C、A、D来表示VSS中的四级权限Read，Check Out，Add，Destroy。
]]>
程序代码
引用内容