[Cvs-dev] Re: cvs-passwd patch, hash.c doubt

[Mark D. Baushke]

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

Prasad J Pandit <address@hidden> writes:

>    Thank you Mark; Thanks for the quick reply. :)
> 
> On Thu, 28 Sep 2006, Mark D. Baushke wrote:
> > ... here is an example of how a given node might
> > get setup and added to the passwdlist
> >
> >   newnode = getnode ();
> >   newnode->type = PASSWDNODE;  /* need to add this to the ntype enum */
> 
>    What is the use/purpose of 'type' field

This is to ensure that the passwd_delproc() is
doing something useful on a node it understands as
well as any code that processes a findnode()
result. It is also useful in debugging your code.

> > You will also need to write a passwd_delproc()
> > that does the right thing to deallocate a node.
> 
>    What about dellist(), delnode(), &
> freenode(), etc. won't thay be sufficient and
> serve the purpose.

I guess that would depend on the nature of your
data block. If it is a structure with other
allocated memory elements, then the default
delproc would cause a memory leak. If it is just a
single memory block, then sure, it would be
possible to leave delproc as NULL.

> > I would expect that the node->data would probably
> > be a struct that includes the real user, password,
> > mapped local user and possibly an indication if
> > the username was found in the CVSROOT/writers
> > and/or CVSROOT/readers files (if they exist).
> 
> 
>    Ummn no!, see!!, but why?? Hey listen!!!, see, I've been using a string 
> like
> 
>      " username[:password[:real username]] "
> 
> It's just the same as, a line in
> 'CVSROOT/passwd' file.

Do you really want to parse that string more than
once?

> And I never had to use the 'CVSROOT/readers' or
> 'CVSROOT/writers' file? 

Well, if you modify the main.c entry, to use
CVS_CMD_MODIFIES_REPOSITORY, then you still won't
have to worry about the problem directly.

The idea is to be concerned about folks hacking an
'anonymous' :pserver: account password which only
the cvs administrator should be allowed to change.

Now, you are allowing a cvs administrator to add a
new local user and password to the repository. I
was not sure if your design would need to also
consider if the user is one that should be
considered a reader or a writer of the repository.

I was just giving an example of some extra field
of information that you might wish to consider to
add to your local data block for the hashnode
being used for your passwordlist.

> Could you please say, how will that be helpful?

Did you read the e-mail from Tony Hoyle?

How about my Message-ID: <address@hidden> message?
In particular this section:

| Things to consider given what Tony said in his
| last message, is that we apparently should make
| certain that the current user is in the
| CVSROOTADM_WRITERS file (CVSROOT/writers) before
| allowing them to change a password.
| 
| If we look at the server.c check_command_valid_p()
| function, we can see that it is already set to do
| this for us if we only make the command table have
| the correct entry.
| 
| So, YOU need to change your patch to main.c for this line:
| 
|     { "passwd",         "pw",       NULL,        passwd,    0 },
| 
| to this:
| 
|     { "passwd",         "pw",       NULL,        passwd,    
CVS_CMD_MODIFIES_REPOSITORY },
| 
| this will automagically prohibit non-writers from
| hacking their password in the repository.
| 
| It is also the case that we may need to do
| something to allow for password attempts that are
| wrong to be properly logged for the cvs
| administrator. It appears right now that you just
| send the user an error() without any other logging
| when they try to do something that they are not
| allowed to do.

I thought my message was pretty clear.

Remember that passwords are very nasty denial of
service vectors in a wide-open Internet.

That said, it may be that your particular use of
the hash.c stuff does not need a complicated data
structure.

Once again, it is late here and I fear I may be
confusing you with my ramblings just before I head
to sleep. I hope you understand what I was trying
to say.

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

iD8DBQFFG46dCg7APGsDnFERAnMvAJ9h1aVr1IWYFD8CsDXUtc0VIYZAWQCeOm2i
+kS7wDtzL6j5aUqJAwR590E=
=qO10
-----END PGP SIGNATURE-----