[Cvs-dev] Re: cvs-passwd patch

[Mark D. Baushke]

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

P J P <address@hidden> writes:

> On Tue, 17 Oct 2006, Mark D. Baushke wrote:
> >>     Yes, true! but, how do I know, if user has done 'cvs login' or
> >> not. I think, the above call is meant to validate that only. And I saw
> >> such use of it, somewhere in cvs code it self.
> >
> > Sure. You see/saw it in login.c which is where the 'cvs login' command
> > is validated before updating the local .cvspass file.
> >
> > However, any other command would have already validated the user via the
> > 'start_server ();' call you made to even be able to ask if the server
> > supported the "passwd" request or not.
> >
> > All you need to do to get the current password is fetch if from the
> > .cvspass file and descramble it, but you really do not even need to
> > do that unless you want to give an error about changing the password
> > to itself or something like that.
> 
>    Oops! I'm extremely sorry Mark!! That call to connect_to_pserver()
> is meant to authenticate the current user, who's trying to change her
> password(Just same as Unix/Linux system 'passwd' does). This call
> comes even after the call to start_server(), which, as you said,
> checks, if the user has done 'cvs login' or not.

No worries. However, I don't see a good reason that a non-administrator
would ever need to change any password other than their own, so if they
were able to authenticate for start_server, then using that username
should be sufficient to prove that they are who they say they are. In
addition, not calling connect_to_pserver() means that any other
authenication method could be used if available. So, if they are able to
run cvs on the local server in :local: mode, the fact that they could
login as that user should be sufficient to indicate that they are able
to change their :pserver: password. Likewise with :ext: or any of the
other methods.

> >  CVS client & server
> >      - "cvs setpass" command is given. The user responds with
> >     a 400 byte pass phrase and somehow managed to type it the
> >     same on the second attempt.
> >  CVSNT client talking to a CVS server
> >     - user attempts to do a "cvs login" and type in their 400 byte
> >       pass phrase. Oops. The CVSNT client is unable to read past the
> >       128 byte limit and the user is therefore unable to login.
> 
>     Oh, okay! That check should be done on clients side or servers??
> 

I believe that a length check should only be done on the client. 

Hmmm... It should probably also only be a warning. If CVSNT ever changes
the maximum, then we should not inhibit it. I have not looked closely to
see if anything else imposes a maximum on the allowed passwords. I see
that you have imposed a minimum which is a fine idea.

> > Sure, and if the user deletes themselves instead of the user they were
> > trying to delete, they now have to go back to some other path than the
> > 'cvs passwd' command to fix the CVSROOT/passwd file. Is that what you
> > want?
> 
>    Well, personally, I wouldn't mind it. As, it takes only ones, for a
> kid to burn his hand, and become careful for the rest of his life, and
> thus wise. But okay, I understand that, everyone is not like me.

:-)

>    Should I just warn about it or abandon any such attempt??

I would abandon the attempt. The current protocol does not really allow
another round trip to the user to ask if they really want to proceed or
not, so best not. I suppose a forcing flag on the command line might be
okay if a user really did want to remove themselves, but I would not put
the effort into that extension right now.

> > You will not like the suggestion... the control flow for the command
> > will be the one you hate that merges passwd() and spasswd() and
> > check_optioN() and checks to see if the server_active is set or not to
> > determine if it is acting as the server or as the client.
> >
> > You parse all of the command-line options for both cases and then
> > determine
> 
>    Okay fine! if that's the *only* way, I'll try...

You have the option of asking the other cvs-dev folks for a vote.
However, I would probably not continue with the integration in that
case.

> > Probably, you have a test case for that in sanity.sh right? (Yes, I know
> > that you do not have such a test case becuase you are using a live
> > :pserver: repository which is one of the problems with the sanity.sh
> > testing you are doing... it is dangerous to expose a live repository to
> > experimental code.)
> 
>    ummn, it need not be a live repository; But yes, remote well setup
> pserver repository us required.

Anything that needs a user to tweak the world of the server as user root
to run a test AND to consider that this untested code will be executing
some instructions as either 'root' or as the 'cvs' user that owns all of
the repositories on the machine is enough to give any sane administrator
problems... granted, we have a number of insane administrators out there
(otherwise they would not be running a read-write :pserver: instance --
yes, this is my bias against :pserver: showing through), but there
really should be a way to exercise the majority of the cvs features
without resorting to using a privileged account at all.

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

iD8DBQFFNKtTCg7APGsDnFERAkLNAJwPzxfIwYKKZy4HuKvVWePDLymyZQCgy2Ur
lOS7pQKW7VGnv+BPzcjmBJA=
=jwQW
-----END PGP SIGNATURE-----