[Cvs-dev] Re: cvs-passwd patch

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

P J P <address@hidden> writes:

> On Thu, 26 Oct 2006, Mark D. Baushke wrote:
> >>     Also, I'm still stuck up with the same authentication problem.
> >> Now, it looks like, authentication for :pserver: & :gserver: is done
> >> with the same 'connect_to_pserver()' and that for :kserver: can be
> >> done with few modifications to 'start_kerberos4_server()', others are
> >> still a mystery.
> >
> > Right. Using connect_to_pserver() is clearly wrong. I have said you
> > should remove it. It should NOT be done in this manner. The problem also
> > exists if SystemAuth=yes in the CVSROOT/config file that the password
> > entry for this user might not actually be in the CVSROOT/passwd file. I
> > have added a poll question for the best way to deal with that situation
> > as well.
> 
>    That seems to make things even more complicated.

I never said this was going to be easy.

> > If you wish to have the client prompt for the old password, then it
> > should be sent to the server along with the new password along the same
> > server connection, but it should NOT initiate another :pserver:
> > connection to do the validation. You could have the passwd() function
> > descramble the old password and do the comparison when you are reading
> > the CVSROOT/passwd file to see if they match if you must do something
> > like it.
> 
>    Yes, that's a good idea. Then, what about SystemAuth=yes, or other
> cases when cvs does not use CVSROOT/passwd authentication?

Hence my addition of another question for our studio audience.

In point of fact, if you really feel you need to prompt for the old
password and use it (which I do NOT agree is desirable), then you will
probably also need to have another server extension to validate it. Of
course, having a password validation step is actually another potential
security hole, although not really a big one.

> > The way I am viewing this problem may be different than others, but
> > I see the 'cvs passwd' file as being a command to manage the
> > CVSROOT/passwd file on a server. If a user can send commands to
> > manipulate it, then they should be able to manipulate their own
> > entry to it and the administrator should be able to manipulate the
> > entries of anyone in the file with the possible exception of
> > disabling/deleting their own entry which CVSNT does not let them do.
> 
>    I'm sure, it's quite able to do that now, isn't it?

Really? Then why are you not able to write sanity.sh tests that test
changing the password without connection via the :pserver: method?

The answer is that you do not yet have it written in a way that is
agnostic with regard to the current connection method. 

On the other hand, the CVSNT code certainly seems to allow a user to use
:ext: or :local: or any of their other authentication methods to change
their :pserver: password. I have no idea why you have not at least made
the attempt to look at their algorithms.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (FreeBSD)

iD8DBQFFQZ7dCg7APGsDnFERAkWxAJ9udE5Hw+/BEyGRL9DW/p7gcFpqqACfVY4q
sQi13ZW19+awIsuFb2GYnuk=
=Sz0a
-----END PGP SIGNATURE-----