Bug 144303 - glibc 2.3.3/2.3.4 - chroot function fail and crash application (proftpd)
glibc 2.3.3/2.3.4 - chroot function fail and crash application (proftpd)
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
: Security
: 150939 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-05 14:42 EST by charvel
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.3.4-10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-14 12:54:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proftpd strace (47.36 KB, text/plain)
2005-01-07 13:18 EST, charvel
no flags Details
proftpd ltrace (294 bytes, text/plain)
2005-01-07 13:19 EST, charvel
no flags Details

  None (edit)
Description charvel 2005-01-05 14:42:46 EST
Description of problem:

Since glibc 2.3.3 shipped with FC3 proftpd defaultroot function does 
not working. I test glibc-2.3.3-97 (early too), 2.3.4-3 - still the 
same


Version-Release number of selected component (if applicable):
glibc-2.3.3-97
glibc-2.3.4-3


How reproducible:
Enable at proftpd.conf option:
DefaultRoot ~
login in to ftp exist account and try ls command

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Bug has been announced at proftpd bugzilla:
http://bugs.proftpd.org/show_bug.cgi?id=2452
http://bugs.proftpd.org/show_bug.cgi?id=2524
Comment 1 Sitsofe Wheeler 2005-01-05 17:46:21 EST
Is there any output in dmesg?
Comment 2 AJ 2005-01-06 15:49:33 EST
Please see this proftpd bug for all the details.

http://bugs.proftpd.org/show_bug.cgi?id=2524
Comment 3 Jakub Jelinek 2005-01-07 10:16:16 EST
Can't reproduce this.
Can you run proftpd under gdb and see where it crashes, or run it once under
strace -f and once under ltrace (in all cases proftpd -n, so that it doesn't
daemonize)?
What's in your nsswitch.conf?
Comment 4 charvel 2005-01-07 13:18:39 EST
Created attachment 109485 [details]
proftpd strace
Comment 5 charvel 2005-01-07 13:19:07 EST
Created attachment 109486 [details]
proftpd ltrace
Comment 6 charvel 2005-01-07 13:25:18 EST
my nsswitch.conf
# grep -v ^# /etc/nsswitch.conf
passwd:     files
shadow:     files
group:      files
hosts:      files dns
bootparams: nisplus [NOTFOUND=return] files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files
netgroup:   nisplus
publickey:  nisplus
automount:  files nisplus
aliases:    files nisplus

Comment 7 AJ 2005-01-10 10:49:38 EST
Do those traces help?  
Comment 8 Jakub Jelinek 2005-01-18 10:00:02 EST
Unfortunatley they don't.  The strace log is incomplete (strace -f -p `pidof
proftpd` proftpd is not useful), it is needed from the start of the program.
Were you running strace -f /usr/sbin/proftpd -n
while no other ftpd's were running or something else?
ltrace log has no info at all.

Does LD_PRELOAD=libSegFault.so proftpd -n print out something?
Comment 9 charvel 2005-01-18 14:43:41 EST
Well, I do:
export LD_PRELOAD=/lib/libSegFault.so
export SEGFAULT_OUTPUT_NAME="/tmp/crash.log"
export SEGFAULT_SIGNALS="all"
export SEGFAULT_USE_ALTSTACK="1"

and got:
*** Segmentation fault
Register dump:

 EAX: 0804f2fc   EBX: 0015c37c   ECX: 08062d58   EDX: 0804f2a0
 ESI: 0015b900   EDI: bffff3b0   EBP: bffff418   ESP: bffff38c

 EIP: 00000000   EFLAGS: 00010206

 CS: 0023   DS: 002b   ES: 002b   FS: 0000   GS: 0000   SS: 002b

 Trap: 0000000e   Error: 00000004   OldMask: 00000000
 ESP/signal: bffff38c   CR2: 00000000

 FPUCW: ffff037f   FPUSW: ffff0000   TAG: ffffffff
 IPOFF: 00000000   CSSEL: 0000   DATAOFF: 00000000   DATASEL: 0000

 ST(0) 0000 0000000000000000   ST(1) 0000 0000000000000000
 ST(2) 0000 0000000000000000   ST(3) 0000 0000000000000000
 ST(4) 0000 0000000000000000   ST(5) 0000 0000000000000000
 ST(6) 0000 0000000000000000   ST(7) 0000 0000000000000000

Backtrace:
/lib/libSegFault.so[0x12839f]
/lib/i686/libc.so.6[0x261a08]
/usr/lib/libexpect.so.0(exp_init_most_cmds+0x22)[0x1431e2]
/usr/lib/libexpect.so.0(Expect_Init+0x177)[0x14cf07]
expect(main+0x5a)[0x804896a]
/lib/i686/libc.so.6(__libc_start_main+0xb3)[0x24e2b3]
expect(exp_interpret_cmdfile+0x49)[0x8048831]

Memory map:

00110000-00125000 r-xp 00000000 03:0d 12069      /lib/ld-2.3.4.so
00125000-00126000 r--p 00014000 03:0d 12069      /lib/ld-2.3.4.so
00126000-00127000 rw-p 00015000 03:0d 12069      /lib/ld-2.3.4.so
00127000-0012a000 r-xp 00000000 03:0d 12091      /lib/libSegFault.so
0012a000-0012b000 r--p 00002000 03:0d 12091      /lib/libSegFault.so
0012b000-0012c000 rw-p 00003000 03:0d 12091      /lib/libSegFault.so
00136000-00137000 rw-p 00000000 00:00 0 
00137000-0015b000 r-xp 00000000 03:05 97203      /usr/lib/libexpect.so.0
0015b000-0015d000 rw-p 00023000 03:05 97203      /usr/lib/libexpect.so.0
0015d000-00160000 rw-p 00000000 00:00 0 
00160000-00203000 r-xp 00000000 03:05 97247      /usr/lib/libtcl8.4.so
00203000-0020d000 rw-p 000a2000 03:05 97247      /usr/lib/libtcl8.4.so
0020d000-0020e000 rw-p 00000000 00:00 0 
0020e000-00210000 r-xp 00000000 03:0d 12116      /lib/libdl-2.3.4.so
00210000-00211000 r--p 00001000 03:0d 12116      /lib/libdl-2.3.4.so
00211000-00212000 rw-p 00002000 03:0d 12116      /lib/libdl-2.3.4.so
00212000-00233000 r-xp 00000000 03:0d 6408       /lib/i686/libm-2.3.4.so
00233000-00234000 r--p 00020000 03:0d 6408       /lib/i686/libm-2.3.4.so
00234000-00235000 rw-p 00021000 03:0d 6408       /lib/i686/libm-2.3.4.so
00235000-00237000 r-xp 00000000 03:0d 12077      /lib/libutil-2.3.4.so
00237000-00238000 r--p 00001000 03:0d 12077      /lib/libutil-2.3.4.so
00238000-00239000 rw-p 00002000 03:0d 12077      /lib/libutil-2.3.4.so
00239000-0035b000 r-xp 00000000 03:0d 6406       /lib/i686/libc-2.3.4.so
0035b000-0035d000 r--p 00122000 03:0d 6406       /lib/i686/libc-2.3.4.so
0035d000-0035f000 rw-p 00124000 03:0d 6406       /lib/i686/libc-2.3.4.so
0035f000-00362000 rw-p 00000000 00:00 0 
00362000-00562000 r--p 00000000 03:05 97380      /usr/lib/locale/locale-archive
00562000-00595000 r--p 00bbc000 03:05 97380      /usr/lib/locale/locale-archive
00595000-0059c000 r-xp 00000000 03:0d 12074      /lib/libgcc_s-3.4.3-20041213.
so.1
0059c000-0059d000 rw-p 00006000 03:0d 12074      /lib/libgcc_s-3.4.3-20041213.
so.1
08048000-08049000 r-xp 00000000 03:05 66276      /usr/bin/expect
08049000-0804a000 rw-p 00000000 03:05 66276      /usr/bin/expect
0804a000-0806b000 rwxp 00000000 00:00 0 
bfffb000-c0000000 rwxp ffffc000 00:00 0 
Comment 10 Jakub Jelinek 2005-01-19 06:25:03 EST
That's a segfault in expect, not proftpd.
Comment 11 charvel 2005-01-19 15:51:56 EST
Well, I recompiled and install new version of expect - still the same - proftpd 
die after ls, but now I cant get output a crash.log
How to trace it? I try:

# gdb /usr/sbin/proftpd
GNU gdb Red Hat Linux (6.3.0.0-0.1rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run -n
Starting program: /usr/sbin/proftpd -n
(no debugging symbols found)
(no debugging symbols found)
cenega.pl - ProFTPD 1.2.10 (stable) (built pon sty 10 10:16:49 CET 2005) 
standalone mode STARTUP

on other session:
# ftp localhost
Connected to localhost (127.0.0.1).
220 ProFTPD 1.2.10 Server (FTP Server) [127.0.0.1]
Name (localhost:root): charvel
331 Password required for charvel.
Password:
421 Service not available, remote server has closed connection
Login failed.
No control connection for command: No such file or directory
ftp>

come back to gdb and got only:
localhost (localhost[127.0.0.1]) - FTP session opened.

Comment 12 AJ 2005-01-21 16:42:32 EST
So this is a bug in expect, not glibc?
Comment 13 Jakub Jelinek 2005-02-07 05:57:03 EST
Another bug against RHEL4 contained a testcase that reproduced likely the
same problem.  Should be fixed with:
http://sources.redhat.com/ml/libc-hacker/2005-02/msg00005.html
Comment 14 Jakub Jelinek 2005-02-14 12:54:05 EST
Should be fixed in glibc-2.3.4-10 in rawhide.
Comment 15 Jakub Jelinek 2005-03-12 03:08:01 EST
*** Bug 150939 has been marked as a duplicate of this bug. ***
Comment 16 Tim Powers 2005-06-09 07:14:33 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-096.html

Note You need to log in before you can comment on or make changes to this bug.