From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1b) Gecko/20020716 Description of problem: running "/usr/sbin/tripwire --init" on a system that uses LDAP for authentication results in a segfault. Version-Release number of selected component (if applicable): tripwire-2.3.1-5 How reproducible: Always Steps to Reproduce: 1.enable LDAP lookups by adding "ldap" after passwd, shadow, and group in /etc/nsswitch.conf 2.run /usr/sbin/tripwire --init Actual Results: [root@delenn root]# /usr/sbin/tripwire --init Please enter your local passphrase: Parsing policy file: /etc/tripwire/tw.pol Generating the database... *** Processing Unix File System *** Software interrupt forced exit: Segmentation Fault Expected Results: database creation should not have crashed Additional info: running strace on tripwire reveals that the segfault ocurrs immediately following loading /etc/nsswitch.conf, which given that I can't reproduce this on a system that's not using LDAP, seems to place the blame pretty squarely on the fact that LDAP name lookups are enabled. The relevant lines out of /etc/nsswitch.conf are: passwd: files ldap shadow: files ldap group: files ldap The tail end of the strace follows: read(4, "search syndicomm.com\nnameserver "..., 4096) = 44 read(4, "", 4096) = 0 close(4) = 0 munmap(0x4007a000, 4096) = 0 socket(PF_UNIX, SOCK_STREAM, 0) = 4 connect(4, {sin_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory) close(4) = 0 open("/etc/nsswitch.conf", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=1733, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4007a000 read(4, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1733 read(4, "", 4096) = 0 close(4) = 0 munmap(0x4007a000, 4096) = 0 --- SIGSEGV (Segmentation fault) --- write(2, "Software interrupt forced exit: "..., 51Software interrupt forced exit: Segmentation Fault ) = 51 munmap(0x40075000, 4096) = 0 munmap(0x40074000, 4096) = 0 _exit(8) = ?
I was able to successfully work around this by installing nscd, but I'm not sure if that's a "real" solution, so I'll leave this open.
FWIW, rpm has this problem too, all statically linked binaries that use getpwnam(3), thereby loading the pam LDAP module, will have this problem. Running nscd is the only solution ATM.