Re: Patch: Fix user authentication + MKDB

[Lars Henriksen]

On Thu, Sep 26, 2002 at 04:16:53PM -0700, Pankaj K Garg wrote:
> > ...
> >          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

Looks OK to me.

> 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.
...
> 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?

As I understand it, MD5 password encryption is built into some versions
of libcrypt, again see the "Keep Track" manual (section C.4),
it's not bad :-)

My system doesn't support MD5 (HAVE_LIBCRYPT undefined) so your patch
wouldn't compile. That was easily fixed by moving things around:

*** gnatsd.c.patch      2002-09-27 14:16:49.000000000 +0200
--- gnatsd.c    2002-09-27 07:50:09.000000000 +0200
***************
*** 253,260 ****
  static int
  password_match (const char *password, const char *hash)
  {
-   char *hashvalue, *encrypted;
- 
    if (strlen(password) && hash)
      {
        if (! strncmp (hash, "$0$", 3))
--- 253,258 ----
***************
*** 265,270 ****
--- 263,270 ----
        else
        {
  #ifdef HAVE_LIBCRYPT
+         char *hashvalue, *encrypted;
+ 
          if (! strncmp (hash, "$1$", 3))
            {
              hashvalue = (char *)hash+3;

Then from the command line:

130$ ./gnatsd -n
200 cluster2.netman.dk GNATS server 4.0-beta1 ready.
user lh
Segmentation fault (core dumped)
131$ dbx gnatsd core
dbx version 5.1
Type 'help' for help.
Core file created by program "gnatsd"

signal Segmentation fault at >*[strlen, 0x3ff800d1d30]  ldq_u   t0, 0(a0)
(dbx) where
>  0 strlen(0x120033f58, 0xf, 0xf, 0x140032660, 0x1200340d4) [0x3ff800d1d30]
   1 xstrdup() ["../../gnats-4/libiberty/xstrdup.c":6, 0x1200340b4]
   2 copy_adm_entry() ["../../gnats-4/gnats/adm.c":6, 0x12001a1f8]
   3 get_responsible_address() ["../../gnats-4/gnats/mail.c":6, 0x120026504]
   4 get_one_responsible_addr() ["../../gnats-4/gnats/mail.c":6, 0x120026738]
   5 get_responsible_addr() ["../../gnats-4/gnats/mail.c":6, 0x120026b60]
   6 gnatsdChdb() ["../../gnats-4/gnats/cmds.c":6, 0x12000b5a0]
   7 GNATS_user() ["../../gnats-4/gnats/cmds.c":6, 0x12000aae8]
   8 serverMainLoop() ["../../gnats-4/gnats/gnatsd.c":6, 0x120009ca0]
   9 main() ["../../gnats-4/gnats/gnatsd.c":6, 0x12000a0e8]
(dbx)

As an aside: if gnatsd for some reason cannot access the responsible file
(or the gnatsd.user_access file for that matter) it silently ignores the fact
which seems rather strange (but has nothing to do with your patch).

By the way, don't forget the GNATS_help() function at the end of cmds.c
and the manual of course (I'm willing to help with that).

Lars Henriksen