[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FAQ-O-Matic pserver protocol

From: Brian Murphy
Subject: Re: FAQ-O-Matic pserver protocol
Date: Tue, 22 Feb 2005 21:45:30 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5

Derek Price wrote:

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

I have plans to impliment pserver with ssl support, it doesn't seem too awful.
Would there be any takers?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]