RE: Patch: Fix user authentication + MKDB

[Pankaj K Garg]

> ...
>          foo:$0$test:edit:
>          *::view:
> 
> Then the behavior IMHO should be:
>  - user foo gives correct password  --> 'edit' access
>  - user foo gives wrong password    --> no access
>  - user foo gives no/empty password --> 'view' access
>  - user bar gives any password      --> no access
>  - user bar gives no/empty password --> 'view' access
> 
> Would that be possible ?
> ...

I'm attaching a patch "gnatspatch.out" with this message that
does this. Seems to work on my small tries here, but would
appreciate if someone else can take a look at it also.

The empty password bit required a change (backwards compatible)
to the protocol. Previously, the client was required to
give:

 USER <name> <password>
 CHDB <db> <name> <password>

Now, clients can give:

 USER <name> [<password>]
 CHDB <db> <name> [<password>]

Hence, the password is optional and will be assumed to be
empty.

For clients to take advantage of this, however, they may
need some modification. For example, gnatsweb assumes that
the user always requires some value for the password.
So, I'm also attaching a patch for gnatsweb ("gnatswebpatch.out")
that takes care of empty password situation.

If the gnats gurus will accept the gnats patch, then I can
submit the gnatsweb patch to the appropriate mailing list.

BTW, the documentation in gnatsd.access states that $1$ implies
use of MD5. In the code I did not find the use of MD5 hashes...
am I missing something here?

Regards

Pankaj

gnatspatch.out
Description: Text document

gnatswebpatch.out
Description: Text document