|
Bugzilla – Full Text Bug Listing |
| Summary: | /bin/login segfaults when run from in.telnetd | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Michal Marek <mmarek> |
| Component: | Basesystem | Assignee: | Thorsten Kukuk <kukuk> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | nadvornik |
| Version: | Beta 2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Found By: | Component Test | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Thie code which seg.faults wasn't touched since years. Works fine if compiled with gcc 3.3, looks like yet another problem with gcc4. Fixed old bug from day one. |
When I install telnet-server on SL10.0 Beta2 and enable the telnet service in /etc/xinetd.d/telnet, I'm unable to login to the machine via telnet, because the /bin/login process segfaults after entering name and password. I did not have much time to debug this, I only know: - The pwdutils-2.6.96-4 package from SL9.3 works if installed on SL10.0B2, pwdutils-3.0.1-2 is broken. - The segfault seems to occur after at least some pam modules are executed, eg. I can read the "You have new mail" message. - The last file opened is /var/run/utmp, the last lines from strace look like this (fd 4 is /var/run/utmp): 20911 execve("/bin/login", ["/bin/login", "-h", "golem.suse.cz", "-p"], ... ... 20911 read(4, "\10\0\0\0002Q\0\0pts/9\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 384 20911 fcntl(4, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0 20911 alarm(0) = 1 20911 rt_sigaction(SIGALRM, {0x403420, [ALRM], SA_RESTORER|SA_RESTART, 0x2aaaaadfc450}, NULL, 8) = 0 20911 --- SIGSEGV (Segmentation fault) @ 0 (0) --- - The bug _might_ be in the file pam_login-3.24/src/login.c, because this one uses some <utmp.h> functions and was changed quite a bit between the versions, but as I said I didn't debug it too much. BTW we use LDAP here if that matters.