实验: 架设vss服务器

新版vss的安装程序只在vs2005DVD里面，vs2010和vs2008都没有vss安装程序.

安装环境: winServer2003Sp1.

 

vs2005安装光盘中的vss2005已经过期了，怪不得公司的vss安装程序是单独的exe.

下载了一个vss2005En, 93M的Zip. 下载点: http://dx1.cr173.com/xl/Microsoft.Visual.SourceSafe.2005.zip

这个url是下载工具提示的最终url, 如果不行, 试下http://dx2..., http://dx3..., 应该有好几个能用的服务器镜像.

 

VSS服务器搭建完成, 效果，可以Add Files, CheckOut,  CheckIn完成了VSS本身的功能。对VSS安全性进行了加强, 防止了普通vss用户拷贝其他工程到工作机.

 

服务器端vss用户和组设置:

vssAdmin登录:

vss用户权限分配:

根目录要有读权限:

没有权限的目录，把权限全部勾掉不选.

有权限的目录不能选'Destroy'权限，这个权限留给VSS大管理员Admin.

vss大管理员登录vss本地客户端，进行工程框架的搭建/

 

不足的地方：在远端登录vss和在VSS服务器本地登录vss时，配置文件(srcsafe.ini)不兼容, 是路径的问题.导致一份配置文件无法同时使客户端和服务器端同时正常运行.

不过服务器段也不经常维护, 在服务器段维护和服务器端运行模式时，准备2份配置文件就可以, 弄一个cmd文件进行切换2份配置文件.

vss服务器端配置文件的切换:

 

安全加强后，要用普通vss用户试一下，看看是否能做vss正常操作外的事情.

vss安全增强后，最终使vss客户端正常运行的配置文件内容:

; srcsafe.ini ; ; Three of these variables -- Data_Path, Users_Path, and Users_Txt -- must ; be in srcsafe.ini. Any other variable here can be overridden in ss.ini. ; Similarly, any ss.ini variable can be placed in srcsafe.ini to set a ; system "default," which individual users can still override in ss.ini. ; The two important paths used by SourceSafe. Data_Path = ../Vss实验库$/data Temp_Path = ../Vss实验库$/temp ; This tells admin where to put personal directories for new users. Users_Path = ../Vss实验库$/users ; From this, find users.txt; from that, in turn, find ss.ini for a user. Users_Txt = ../Vss实验库$/users.txt ; The following line contains common file groupings. File_Types = VB (*.vb;*.resx;*.xsd;*wsdl;*.vbproj;*.sln;*.cls;*.bas;*.vb?;*.fr?), VC (*.c;*.cpp;*.cxx;*.vcproj;*.sln;*.def;*.ds?;*.h;*.hpj;*.hpp;*.hxx;*.ico;*.inl;*.mak;*.rc;*.rc2;*.rgs;*.bmp;*.cur), WEB (*.aspx;*.ascx;*.asmx;*.master;*.asax;*.config;*.asa;*.asp;*.css;*.dbp;*.dtq;*.ht?;*.htm*;*.pkp;*.sql;*.stm;*.sct;*.htx;*.shtml;*.alx), VCSharp (*.cs;*.csproj;*.sln), VJSharp (*.jsl;*.java;*.vjproj;*.vjp;*.sln), XML (*.xml;*.xsl;*.xsd;*.xslt;*.xsx;*.xss) PrjEntryTimeout = 15 Multiple_Checkouts = Yes Checkout_LocalVer_Disabled = No UseHelperService = Yes [TimeZone] Name = (GMT+08:00) 北京，重庆，香港特别行政区，乌鲁木齐 TZ_Bias = -480 TZ_DaylightBias = -60 TZ_DaylightDate = 0000/00/00 00:00:00.000 TZ_StandardBias = 0 TZ_StandardDate = 0000/00/00 00:00:00.000 TZ_UseDaylightSavingTime = Yes [$/] Shadow = ../Vss实验库$/shadowFolder

user.txt

Admin = ./users/admin/ss.ini Vss_usr_experiment = ./users/vss_usr_/ss.ini

环境配置抓图:

VSS服务器安装时的选择项, 这样可以多人修改, 合并, 不用等一个人完事了，另一个人再来. 有点cvs的意思了.

vss目录权限设置之前

vss目录权限设置之后, 这个文件夹只共享给vss用户.

加强之后其他目录抓图:

vss目录分成2个目录: vss目录共享给vss用户, vsData目录不共享, 2个配置文件分开.

vss目录权限设置:

vssData目录设置:

 配置过程可能记录的不全，不过没关系。

设置完后，先在vss服务器端, 进行管理员登录，vss本地登录, 看看是否正常。

然后，在客户端登录测试不正常的行为.

 

vss用户首先是个服务器端Windows的用户，然后才是vss的用户. 名称是一样的.

 

1. 用vss用户直接登录网络邻居, 例如: //192.168.1.x/实验库(vss库共享文件夹), 看是否能拷贝出目录或文件，是否能修改或替换配置文件, 如果有问题，转到上面图例，进行调整. 主要是对windows用户权限的设置, vss用户的设置， 共享文件夹vss的设置和隐藏的vssData的设置.

 

2. 在远端登录vss后, 在vss界面内, 看是否能做权限之外的事情，比如，是否能点开没有权限的目录, 是否能看到权限之外的内容,  是否能迁出权限之外的工程。

 

如果测试通不过，按照参考图，进行设置， 主要是对windows用户权限的设置, vss用户的设置， 共享文件夹vss的设置，隐藏的vssData目录的设置， 2个配置文件的设置. 我这的vss服务器已经测试了上面两点，通过测试.

 

vss服务器架设完成，此文档抓图不全. 大概的过程记录如此，剩下就是调整和测试可用性，安全性.

 

<2011_0319>

假设权限要设置到项目(实际应用中就是这样), 为了防止由于疏忽引起的权限分配不当，减少设置给新用户分配权限后，需要做的详细权限测试。感觉应该对每个项目设立一个用户组，最开始建立权限时，vss共享文件夹的安全加强都是针对VSS用户组. 这样，如果需要增加用户的项目权限时， 就把用户加入此项目的vss用户组就可以了。不用再担心用户有额外的权限.

 

用户组定义 DEMO工程 => VSS用户组_DEMO工程 experiment => VSS用户组_experiment 基础库 => VSS用户组_基础库 业务库 => VSS用户组_业务库 正式工程 => VSS用户组_正式工程 在实际的工程中, 正式工程之外的公用库可以分别只设立一个用户组. 正式工程下的项目要每个项目分别设立用户组. 假设正式工程中的目录结构如下: 正式工程/ 正式工程/Project1 正式工程/Project2 正式工程/Project3 正式工程/ProjectN 正式工程/ProjectN+1 那么需要建立的用户组为 正式工程/ => VSS用户组_正式工程(这个用户组是主管和管理员权限) 正式工程/Project1 => VSS用户组_Project1 正式工程/Project2 => VSS用户组_Project2 正式工程/Project3 => VSS用户组_Project3 正式工程/ProjectN => VSS用户组_ProjectN 正式工程/ProjectN+1 => VSS用户组_ProjectNPlus1

默认情况下, 不能为每一位VSS用户分配不同权限. 需要打开权限分配选项.

设置影子文件夹

实验结论:

  vss不能阻止低级别VSS用户通过直接登录共享文件夹的方式拷贝权限外的文件夹, 安全性真差.

  VssData共享成文件夹必须给所有Vss用户全部的权限, 否则Vss远端登录操作不正常.

 

  把VssData文件夹共享成VssData$的方法，只能阻止用户看不到， 但是从srcsafe.ini中可以看出VssData的位置.

  直接去访问VssData共享夹就对代码库的安全性问题构成了严重威胁.

 

  希望还能有别的方法加固Vss. 很奇怪，这样的安全性，还能用于代码管理么？ 如果是这样的安全性，根本不能保证代码库的安全性.