Derek Price wrote:
I have plans to impliment pserver with ssl support, it doesn't seem too awful.-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Larry Jones wrote:
| Guus Leeuw jr. writes: | |> I take this as a veto for no switches, but merely "cvs passwd" |> which would run only: a) if pserver protocol b) the user in |> questo is listed in CVSROOT/passwd on the pserver | | | I don't even like the idea of doing that, but I won't veto it if | Derek and Mark think it's a good idea.
Given the security deficiencies already inherent in the pserver protocol, I can't see much harm in allowing passwords to be changed via a CVS interface. Requiring a user to type perl in on the shell command line to change a CVS password doesn't seem to me to add much additional security when the passwords are already so easily compromised. Might as well allow users who have already decided pserver is secure enough for them the convenience of a passwd interface.
Hrm. Then again, the more I consider the implications of a `cvs passwd' command, the less appealing it sounds. Firstly, in the recommended pserver configuration, if you fail to heed all the dire warnings we provide about pserver in the first place, the CVS team recommends that the CVSROOT module only be writable by members of some cvs admin group, perhaps `cvsadmin', since otherwise anyone could check in a CVSROOT/passwd file, add it to CVSROOT/checkoutlist, and overwrite your passwd file, mapping their account to any user on the system that they wished, other than root.
To work around this in such a way as to allow any user to change their own password, a few possible solutions come to mind. The cvs pserver would need to either keep root privileges longer than it currently does, an option which is definitely out or, alternatively, perhaps a second `cvspasswd' executable with setgid cvsadmin privileges could be installed. This sounds slightly more secure, but still opens the possibility of new weaknesses in the `cvspasswd' executable.
Perhaps some reasonable compromise could be reached, possibly involving relocation of the CVS passwd file into /etc/cvs/ or somesuch as has been suggested in the past, but most of what I can come up with still involves the potentially dangerous setgid executable.
The stated position of the CVS team has been to recommend using some sort of :ext:/ssh access combination using system userids when security is a concern. This is an acknowledgement that CVS gets few security audits and it is best to rely on tools that do get thorough security audits for CVS access. This also saves on the time of the CVS maintainers by allowing us to leverage existing tools where security is concerned.
I am still willing to discuss this matter, particularly because my personal design philosophy tends to favor new features as progress, with faith that the problems in a new design will be discovered and solved later, but, at the risk of sounding stifiling, the potential for new security issues arising in the already flawed pserver design is real and I think these issues need to be addressed before anything like this should be adopted.
Then again, perhaps the right approach would be to allow the passwd command but continue to recommend clamping down permisions on CVSROOT such that it can't be used. This does sounds like a contradictory position, though, and might help mislead naive and beginning users. I guess I'm with Larry, at least until these issues are satisfactorily addressed.
Would there be any takers?
/Brian
_______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs