实验: 架设vss服务器

    技术2022-05-19  20

    新版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. 很奇怪,这样的安全性,还能用于代码管理么? 如果是这样的安全性,根本不能保证代码库的安全性.

     


    最新回复(0)