Subject: help debugging x86 solaris w/wu-ftpd 2.5.0

From: Ron Snyder <[email-masked]>
Date: Mon, 21 Jun 1999 14:35:06 PDT

OK, it's me again.  I wrote a few weeks ago because my newly built
ftpd daemon (now 2.5.0) keeps failing when I try to login as a valid
user.  

(quick refresh-- if I try to login as a disallowed person first, and
then try as an allowed user, it seems to work, but if the first attempt
is the allowed user, then it fails.)

I am seeing this only with wuftpd, but I'm not really convinced it's a 
wuftp error.  I'm writing to the list in hopes that someone here has
seen something like the gdb backtrace that follows:

Attaching to program `/usr/local/src/wu-ftpd-2.5.0/bin/ftpd', process 15375    
Reading symbols from /usr/lib/libsocket.so.1...done.
Reading symbols from /usr/lib/libnsl.so.1...done.
Reading symbols from /usr/lib/libc.so.1...done.
Reading symbols from /usr/lib/libdl.so.1...done.
Reading symbols from /usr/lib/libmp.so.2...done.
Symbols already loaded for /usr/lib/libsocket.so.1
Symbols already loaded for /usr/lib/libnsl.so.1
Symbols already loaded for /usr/lib/libc.so.1
Symbols already loaded for /usr/lib/libdl.so.1
Symbols already loaded for /usr/lib/libmp.so.2
0xdff0d39c in _read () from /usr/lib/libc.so.1
(gdb) cont
Continuing.
 
       <========== at this point in my other window I attempt to
                   log in as 'snyder'.  I never receive the password
                   prompt

Program received signal SIGSEGV, Segmentation fault.
0xdff19be0 in t_splay () from /usr/lib/libc.so.1
(gdb) bt
#0  0xdff19be0 in t_splay () from /usr/lib/libc.so.1
#1  0xdff19a36 in t_delete () from /usr/lib/libc.so.1
#2  0xdff1982a in realfree () from /usr/lib/libc.so.1
#3  0xdff19d2e in cleanfree () from /usr/lib/libc.so.1
#4  0xdff1943a in _malloc_unlocked () from /usr/lib/libc.so.1
#5  0xdff192e9 in malloc () from /usr/lib/libc.so.1
#6  0xdff3316f in _findbuf () from /usr/lib/libc.so.1
#7  0xdff34b94 in fgets () from /usr/lib/libc.so.1
#8  0x805098b in checkuser (name=0x807beb8 "snyder") at ftpd.c:1961
#9  0x805080c in user (name=0x807beb8 "snyder") at ftpd.c:1840
#10 0x805c330 in yyparse () at ftpcmd.c:235
#11 0x804f9d2 in main (argc=10, argv=0x8047d38, envp=0x8047d64) at ftpd.c:1156
#12 0x804e7f3 in _start ()

It does appear to be something in libc, but they're exactly the same
as one of my other machines.  Ideas?

-ron

---

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 21 Jun 1999 19:46:17 -0400 (EDT)

> as one of my other machines.  Ideas?

Try again.  This time delete your ftpusers file.  Then add ftpaccess
clauses to obtain the same effect.  I'm on Linux here and all my normal
users are UID >= 100 and GID >= 100 so I use the following:

deny-uid %-99
deny-gid %-99
allow-uid ftp
allow-gid ftp

This does the same job as ftpusers; only faster, more accurately and with
less change of my forgetting someone.

-- 

Gregory A Lundberg              Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: Ron Snyder <[email-masked]>
Date: Tue, 22 Jun 1999 8:59:14 PDT

> users are UID >= 100 and GID >= 100 so I use the following:

is there default end to that range, or should it really be:
deny-uid %-99 %99
deny-gid %-99 %99

> allow-gid ftp

Thanks for the suggestion, I like this method better than the misnamed (!?)
'ftpusers' file.  It still fails, but with a different traceback:

#0  0xdff19be0 in t_splay () from /usr/lib/libc.so.1
#1  0xdff19a36 in t_delete () from /usr/lib/libc.so.1
#2  0xdff1982a in realfree () from /usr/lib/libc.so.1
#3  0xdff19d2e in cleanfree () from /usr/lib/libc.so.1
#4  0xdff1943a in _malloc_unlocked () from /usr/lib/libc.so.1
#5  0xdff192e9 in malloc () from /usr/lib/libc.so.1
#6  0x8061517 in hostmatch (addr=0x807d3cc "*.*.*.*", 
    remoteaddr=0x807ac6a "167.128.1.73", 
    remotehost=0x807868c "virtweb3.lblesd.k12.or.us") at access.c:302
#7  0x8062ad3 in acl_getclass (classbuf=0x8046e24 "all") at access.c:777
#8  0x8063fbc in access_ok (msgcode=530) at access.c:1517
#9  0x80508b7 in user (name=0x807beb8 "snyder") at ftpd.c:1866
#10 0x805c330 in yyparse () at ftpcmd.c:235
#11 0x804f9d2 in main (argc=10, argv=0x8047d38, envp=0x8047d64) at ftpd.c:1156
#12 0x804e7f3 in _start ()

Here's the original traceback again:

[time passes for our luckless victim...]
Well, I think I've got some good news-- I'm an idiot.  After looking at
these two tracebacks, I decided to see if just by chance there were any 
patches available for x86 malloc.  Bingo.  I just installed 105211-18
and my problem seems to have disappeared.  I'll let you know if I find 
any more problems (AFTER I've checked for patches this time...).

Thanks again!

-ron

---

From: Gregory A Lundberg <[email-masked]>
Date: Tue, 22 Jun 1999 12:10:58 -0400 (EDT)

> is there default end to that range, or should it really be:

%-99 means "From lowest-possible value up to and including ID 99" so your
form gains nothing.

> Well, I think I've got some good news-- I'm an idiot.  After looking
> at these two tracebacks, I decided to see if just by chance there were
> any patches available for x86 malloc.  Bingo.  I just installed
> 105211-18 and my problem seems to have disappeared.  I'll let you know
> if I find any more problems (AFTER I've checked for patches this
> time...).

Always a good idea.  From what I've seen, more so with Sun software.

--