Hide Forgot
when using USEDB=yes in authconfig, and updating to this nss_db version, ssh logins stop working. /var/log/secure has: Jul 22 21:36:14 hostname sshd[23555]: fatal: mm_request_send: write: Broken pipe and running a /usr/sbin/sshd on another port in debug mode shows: # /usr/sbin/sshd -d -p 8838 debug1: sshd version OpenSSH_5.3p1 debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: rexec_argv[2]='-p' debug1: rexec_argv[3]='8838' debug1: Bind to port 8838 on 0.0.0.0. Server listening on 0.0.0.0 port 8838. debug1: Bind to port 8838 on ::. Server listening on :: port 8838. debug1: Server will not fork when running in debugging mode. debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from 75.148.32.185 port 39348 debug1: Client protocol version 2.0; client software version OpenSSH_5.6 debug1: match: OpenSSH_5.6 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.3 debug1: permanently_set_uid: 74/74 debug1: list_hostkey_types: ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-ctr hmac-md5 none debug1: kex: server->client aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user kevin service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for "kevin" debug1: PAM: setting PAM_RHOST to "example.com" debug1: PAM: setting PAM_TTY to "ssh" debug1: userauth-request for user kevin service ssh-connection method publickey debug1: attempt 1 failures 0 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 100037/100037 (e=0/0) sshd: kevin [priv]: symbol lookup error: /lib64/libnss_db.so.2: undefined symbol: __libc_alloca_cutoff debug1: do_cleanup mm_request_send: write: Broken pipe Downgrading to nss_db-2.2.3-0.3.pre1.el6.x86_64.rpm fixes the issue.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
Additionally, this nss_db seems to cause rhel6 xen (or kvm) guests to panic on boot. I've not tried it on a bare metal machine. From a xen guest case: blkfront: xvda: barriers disabled xvda: xvda1 xvda2 xvda3 dracut: Scanning devices xvda3 for LVM logical volumes GuestVolGroup00/root dracut: inactive '/dev/GuestVolGroup00/root' [7.72 GiB] inherit EXT4-fs (dm-0): INFO: recovery required on readonly filesystem EXT4-fs (dm-0): write access will be enabled during recovery EXT4-fs (dm-0): recovery complete EXT4-fs (dm-0): mounted filesystem with ordered data mode dracut: Mounted root filesystem /dev/mapper/GuestVolGroup00-root dracut: Loading SELinux policy type=1403 audit(1311367267.760:2): policy loaded auid=4294967295 ses=4294967295 dracut: dracut: Switching root udev: starting version 147 Initialising Xen virtual ethernet driver. kjournald starting. Commit interval 5 seconds EXT3-fs (xvda1): using internal journal EXT3-fs (xvda1): mounted filesystem with ordered data mode Adding 2097144k swap on /dev/xvda2. Priority:-1 extents:1 across:2097144k SS Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: init Not tainted 2.6.32-131.6.1.el6.x86_64 #1 Call Trace: [<ffffffff814da518>] ? panic+0x78/0x143 [<ffffffff81300366>] ? get_current_tty+0x66/0x70 [<ffffffff8106c452>] ? do_exit+0x852/0x860 [<ffffffff8106c4b8>] ? do_group_exit+0x58/0xd0 [<ffffffff8106c547>] ? sys_exit_group+0x17/0x20 [<ffffffff8100b172>] ? system_call_fastpath+0x16/0x1b
Just to clarify, when the guest panics, are you talking about nss_db in the guest, or on the host?
In the guest. Downgrading the guest's nss_db causes it to boot ok again.
Whoa, how'd I miss that 'undefined symbol' error? This isn't the weird signal-handling thing I suspected it would be, after all.
The new package depends on a glibc change (bug #705465, the fix for which makes __libc_alloca_cutoff externally-accessible for us here) that at this time is still in the queue.
Created attachment 515928 [details] work around __libc_alloca_cutoff() not being available by acting as though it always fails
It looks like the glibc update has been released: https://rhn.redhat.com/rhn/errata/details/Details.do?eid=12021 Kevin, does this resolve the problem you're seeing? Based on a quick peek at the symbol table in the updated glibc package, I believe it will.
I can confirm that this fixes the issue I was seeing. ;) Thanks.
Awesome. I guess I can mark this as closed->errata, then, even if it ended up being fixed by a glibc erratum rather than an nss_db one.