首先,你可能需要 $CVSROOT 和 $CVSROOT/CVSROOT 上设定权限。 见 Password authentication security。
在服务器端,需要编辑文件 /etc/inetd.conf 让 inetd
它在正确的端口上收到一个连接的时候运行 cvs pserver
命令。
按照默认,端口号是 2401;当然,如果客户端用 CVS_AUTH_PORT
重新编译了就会有一些不同。
也可以在 CVSROOT 变量(参阅 Remote repositories)指定或用 CVS_CLIENT_PORT 环境变量(参阅 Environment variables)跨越。
如果你的 inetd
在 /etc/inetd.conf 中允许原始的端口号定义,那么下面的命令就足够了(所有命令在 inetd.conf 中都是单行):
2401 stream tcp nowait root /usr/local/bin/cvs cvs -f --allow-root=/usr/cvsroot pserver
(你也可以使用 `-T' 选项来指定一个临时目录。)
`--allow-root' 选项指定一个允许的 cvsroot 目录。
试图使用一个另外的 cvsroot 目录的客户将被拒绝连接。
如果你希望设置多个允许的 cvsroot 目录,重复设置这一选项就行了。
(不幸的是,许多版本的 inetd
对参数的数量和/或命令长度小有限制。
通常解决方法是在 inetd
中运行一个 shell 脚本,然后在脚本中调用 cvs 所需的参数。)
如果你希望 inetd
使用符号服务名称来代替原始端口号,那么把它放进 /etc/services 里:
cvspserver 2401/tcp
并且在 inetd.conf 中使用 cvspserver
代替 2401
。
如果你的系统用 xinetd
替代 inetd
,步骤有些不同。
创建一个叫 /etc/xinetd.d/cvspserver 的文件,包含下列内容:
service cvspserver { port = 2401 socket_type = stream protocol = tcp wait = no user = root passenv = PATH server = /usr/local/bin/cvs server_args = -f --allow-root=/usr/cvsroot pserver }
(如果已在 /etc/services 中定义 cvspserver
,可以省略 port
这一行。)
做了上面的修改之后,需要重新启动你的 inetd
,或者采取其它可以使它重新读取初始化文件手段。
如果设置这有麻烦,参阅 Connection。
因为客户端以明文存储和传输口令(几乎是—请见 Password authentication security),通常使用了一个独立的 cvsCVS 口令文件,这样人们访问仓库的时候不会危及定期口令的安全。 这个文件是 $CVSROOT/CVSROOT/passwd (参阅 Intro administrative files)。 除了只用较少的域(cvs 用户名称,可有可无的口令和服务器的用户名称)以外,它的格式和 Unix 上的 /etc/passwd 相似,采用分号分隔。 这里是个有五个表项的例子 passwd 文件:
anonymous: bach:ULtgRLXo7NRxs spwang:1sOp854gDF3DY melissa:tGX1fS8sun6rY:pubcvs qproj:XR4EZcEs0szik:pubcvs
(口令使用 Unix 标准的 crypt()
函数加密,因此它可以直接从常规 Unix /etc/passwd 文件粘贴过来。)
例子中第一行允许任何 cvs 客户机使用 anonymous
来访问,口令可以用任意字符还可以用空口令。
(这是一个站点允许匿名进行只读访问的典型用法;“只读(read-only)”部分信息的做法,参看 Read-only access。)
如果他们提供各自的明文口令第二、三行允许对 bach
和 spwang
进行访问。
如果她提供正确的口令第四行允许对 melissa
访问,但她的 cvs 操作将实际运行在服务器侧的 pubcvs
用户名下。
虽然系统上不须有 melissa
用户名,但 必须 使用 pubcvs
。
第五行显示系统用户标识可以共享:作为 qproj
成功认证的任何客户实际将按 pubcvs
来运行,和 melissa
所做的一样。
用这种方法你可以在你的仓库中为每个项目创建一单个共享的系统用户,并且在 $CVSROOT/CVSROOT/passwd 文件中为每个开发者设置一行。
每行的 cvs 用户名应该不同,而系统用户名应该相同。
用不同的 cvs 用户名目的是在 cvs 将在其名字下记录其动作: 当 melissa
提交了项目中的一个修改,检入被纪录在项目历史中的 melissa
名下,而不是 pubcvs
下。
而共享一个系统用户的原因是可以安排仓库中相关区域的权限,只有那个帐户有写权限。
如果系统用户域存在的时候,全部口令鉴定 cvs 命令按该用户运行;如果没有指定系统用户,cvs 简单地取 cvs 用户名作为系统用户名并且按此户名运行命令。 无论哪种情况,如果系统上没有这样的用户,于是 cvs 操作会失败(不管客户机是否提供了正确的口令)。
口令和系统用户字段都可以省略(如果系统用户字段省略,那么与口令分隔的冒号也省略)。 例如,这将是有效的 $CVSROOT/CVSROOT/passwd 文件:
anonymous::pubcvs fish:rKa5jzULzmhOo:kfogel sussman:1sOp854gDF3DY
当口令字段为空,客户的认证可以用包括空字符串在内的任何口令。 但 cvs 用户名后的分隔冒号必需存在,即使口令为空。
cvs 还可借助于系统认证。
认证口令的时候,服务器先检查 $CVSROOT/CVSROOT/passwd 文件中的用户。
如果找到用户,就按上面说的方法使用该项进行认证。
如果没有找到,或 cvs passwd 文件不存在,服务器将采用操作系统的用户认证机制(这种机制可以通过设置 cvs config 文件中的 SystemAuth=no
来禁止,参阅 config)。
除非系统中有 PAM(Pluggable Authentication Modules),或者 cvs 服务器端编译的时候配置 (使用 ./configure --enable-pam
- 参考 INSTALL 中的说明),否则默认的回调(callback)是查找 /etc/passwd 中的口令。
在此情况下,将磋商以 PAM 代替。
这意味着可以配置 cvs 使用 PAM 提供的各种口令认证方式(可能是 UNIX password,NIS,LDAP,或其他),这取决于 PAM 的全局配置文件(通常在 /etc/pam.conf 或可能是 /etc/pam.d/cvs)。
详细配置 PAM 的方法请参考 PAM 的文档。
注意,PAM 是 cvs 中使用的实验特性,鼓励反馈信息。
如果你使用了 PAM 支持,请发邮件到 cvs 的邮件列表(info-cvs@gnu.org
或 bug-cvs@gnu.org
)。
警告:采用 PAM 可以给系统管理员更多的 cvs 认证灵活性,但并不比别的方法有更高的安全性。 详见下。
CVS 在 PAM 配置文件里需要“auth”,“account”和“session”模块。 因此典型的 PAM 配置是在文件 /etc/pam.conf 里模拟标准的 cvs 系统 /etc/passwd 认证:
cvs auth required pam_unix.so cvs account required pam_unix.so cvs session required pam_unix.so
对等的 /etc/pam.d/cvs 文件里包括
auth required pam_unix.so account required pam_unix.so session required pam_unix.so
一些系统要求给出模块的完整路径,因此 pam_unix.so (Linux) 改为类似 /usr/lib/security/$ISA/pam_unix.so.1 (Sun Solaris)。 参考 cvs 源码发布子目录 contrib/pam 中更多的配置例子。
PAM 中指出的服务名“cvs”是默认配置中的服务名,也可以在编译前使用 ./configure --with-hardcoded-pam-service-name=<pam-service-name>
重新设置。
cvs 也可以被设置成调用其他的名字 ./configure --without-hardcoded-pam-service-name
,但这个特性只有你有权控制 cvs 用什么名字时才有效。
要知道,在使用系统认证时会有安全漏洞:cvs 操作时是使用系统中用户的正规注册口令,而该口令网络传输中是采用明码方式。 见 Password authentication security。 这点对使用 PAM 认证会有更多的问题,因为系统口令的源头是某些像 LDAP 的中心服务,而 LDAP 它还被用于认证别的服务。
另一方面,PAM 使得定期地修改口令非常容易。 如果对全部活动给用户一个口令系统的选项,用户经常定期改变他们的口令。
在非 PAM 的配置中,口令是保存在 CVSROOT/passwd 文件里面,因为只有管理员用户(或有等同的权限)才有此文件的修改访问权限,所以想用定期改变口令会很困难。 可以采用设计的网页程序或 set-uid 程序来更新文件,或者是提交请求让管理员进行手动修改来更新。 第一种情况下,必须记住去定期更新各自的口令可能是很困难的。 第二种情况下,手工的本性将是只有绝对必要时才会去修改口令。
注意,PAM 管理员应避免在 cvs 证明/授权(authentication/authorization)中采用配置一次性口令 OTP。 如果用 OTP,管理员最好考虑其他的 Client/Server 访问方式。 参阅 Remote repositories 获得其他方法的列表。
现在,cvs passwd 文件里加入口令的唯一方法是从别处粘贴而来。
也许有一天,会有一条命令 cvs passwd
。
不像其他在 $CVSROOT/CVSROOT 目录下的文件,可以在不是通过 cvs来编辑 passwd 的地方进行编辑。 这是因为使 passwd 文件检出为人们的工作副本可能的安全风险。 如果你的确需要将 $CVSROOT/CVSROOT 中的 passwd 检出,参看 checkoutlist。